TWI442333B - Method and system for enabling item-level approval of payment card - Google Patents

Description

Method and system for project level approval for payment cards

The present invention relates generally to electronic commerce and, more particularly, to electronic payment systems.

Payment is known using a payment card such as a credit card, a debit card, a card holding a balance, and the like. Typically, in a transaction that recognizes the use of such a card, whether or not the card holder has a sufficient balance or credit limit in view of the situation, recognizes or does not recognize a total required amount. Such "all or nothing" recognition does not meet the needs of new applications for electronic payment technology.

Therefore, there is a need for a more flexible approach.

The principles of the present invention provide techniques for achieving project level approval for a payment card (or other payment device). An exemplary embodiment of a method for such electronic payment verification (which may be computer implemented) in accordance with an aspect of the present invention includes the steps of facilitating obtaining an identification for an interaction in conjunction with an inbound authorization request Pointing to the indicator of the individual item purchased; facilitating the translation of the indicator into a form known to a third party transaction approver to obtain the translated indicator; and facilitating transmission of the translated indicator to the third party transaction approver for Individual projects are verified on a project-by-project basis. The transmission of the translated indicator is combined with a departure authorization request.

An exemplary embodiment of an apparatus for electronic payment verification in accordance with another aspect of the present invention includes a memory and at least one processor coupled to the memory. The processor is operative to perform, for example, one or more of the method steps just described.

In another aspect, a method for establishing a database useful in facilitating electronic payment verification (which can be implemented by a computer) includes the steps of facilitating pre-registration via a plurality of vendors for identifying purchases. Supplier indicators for individual projects, together with the identity and cost of such projects. Among a given supplier, at least some of the supplier metrics are different for the same item purchased. The method additionally includes the additional step of facilitating the generation of a translation database having a single translated indicator associated with one of each given item, regardless of whether a given supplier has different supplier metrics associated with the given item . The method additionally includes the additional steps of facilitating storing the translation database in a form and facilitating the easy translation of a given supplier indicator into a corresponding translated indicator based on the given supplier indicator and associated with the One of the given supplier metrics is a given supplier.

An exemplary embodiment of an apparatus for establishing a database useful in facilitating electronic payment verification in accordance with another aspect of the present invention includes a memory and at least one processor coupled to the memory. The processor is operative to perform, for example, one or more of the method steps just described.

Additionally, one or more of the method steps of the present invention can be implemented in the form of a product comprising a machine readable medium containing one or more programs that, when executed, perform such steps.

The techniques of the present invention can provide substantially advantageous technical effects. Such may include, for example, reducing or eliminating the need for a third party approver to maintain multiple data sheets, thus resulting in faster processing times.

These and other features and advantages of the present invention will become apparent from the <RTIgt;

Attention should now be directed to Fig. 1, which depicts an exemplary embodiment of a system 100 in accordance with an aspect of the invention and which includes various possible components of the system. System 100 can include one or more different types of portable payment devices. For example, one such device can be a contact device such as card 102. Card 102 can include an integrated circuit (IC) die 104 having a processor portion 106 and a memory portion 108. A plurality of electrical contacts 110 can be provided for communication purposes. In addition to or in lieu of card 102, system 100 can be designed to operate with a contactless device such as card 112. The card 112 can include an IC die 114 having a processor portion 116 and a memory portion 118. An antenna 120 can be provided for contactless communication using, for example, radio frequency (RF) electromagnetic waves. One or more of the oscillator(s) and/or additional suitable circuitry for modulation, demodulation, down conversion, and the like may be provided. It should be noted that the cards 102, 112 are exemplary of a wide variety of devices that can be employed by the techniques of the present invention. Other types of devices may include a conventional card 150 having a magnetic strip 152, a suitably configured cellular telephone handset, and the like. Indeed, the techniques of the present invention can be adapted to different types of cards, terminals, and other devices.

The ICs 104, 114 may include processing units 106, 116 and memory units 108, 118. Preferably, the ICs 104, 114 may also include one or more of control logic, a timer, and an input/output port. Such components are well known in the art of IC technology and are not described separately. One or both of the ICs 104, 114 may also include a co-processor, as such, which is well known and not separately described. The control logic can provide the necessary control in conjunction with the processing units 106, 116 to handle communication between the memory units 108, 118 and the input/output ports. The timer can provide a timing reference signal from the processing units 106, 116 and the control logic. The coprocessor can provide, for example, the ability of a cryptographic algorithm to determine the required immediate execution of complex computations.

The memory portions or units 108, 118 may comprise different types of memory, such as volatile and non-volatile memory, and read only and programmable memory. The memory units can store, for example, transaction card data such as a user's personal identification number ("PIN"). The memory portions or units 108, 118 can store the operating systems of the cards 102, 112. The operating system loads and executes applications and provides file management or other basic card services to such applications. An operating system that can be used to implement the present invention is MULTOS licensed by StepNexus Inc. working system. In addition, based on JAVA CARD ^TM technology can be used (by the Sun Microsystems Inc., 4150 Network Circle, Santa Clara, CA 95054 USA license) them with JAVA CARD ^TM-based operating system, or can be made of proprietary operating systems from several vendors. The operating system is preferably stored in a read only memory ("ROM") within the memory portions 108, 118. In an alternative embodiment, flash memory or other non-volatile and/or volatile memory types may also be used in the memory cells 108, 118.

In addition to the basic services provided by the operating system, the memory portions 108, 118 may also include one or more applications. Currently, one of the possible standards that such applications can comply with is the EMV payment standard disclosed by EMVCo, LLC (http://www.emvco.com). It will be appreciated that the application can be configured in a variety of different ways.

As noted, the cards 102, 112 are examples of a wide variety of payment devices that can be employed by the techniques of the present invention. The primary function of such payment devices may not be payment, for example, it may be a cellular telephone handset embodying the technology of the present invention. Such devices may include cards with a conventional form factor, smaller or larger cards, cards of different shapes, key rings, personal digital assistants (PDAs), suitably configured cellular telephones, or indeed implemented Any device capable of the capabilities of the present technology. The card or other payment device may include a body portion (eg, a laminated plastic layer of a payment card, a PDA case or chassis, a wafer assembly, and the like), a memory 108 associated with the body portions, 118, and processors 106, 116 associated with the body portions and coupled to the memory. The memories 108, 118 may contain suitable applications. The processors 106, 116 are operative to perform one or more method steps. The applications may be, for example, application identification items (AIDs) that are linked to the firmware in the form of data in a card memory such as an electronic erasable programmable read only memory (EEPROM). Software code. Similarly, it should be noted that a "smart" card is not necessarily required, and a conventional magnetic stripe card can be used.

System 100 can employ several different types of terminals. Such a terminal can include a contact terminal 122 configured to interface with the contact type device 102; a wireless terminal 124 configured to interface with the wireless device 112; a magnetic strip terminal 125, the group thereof The state is interfaced with a magnetic strip device 150; or a combined terminal 126. The combination terminal 126 is designed to interface with any type of device 102, 112, 150. Some terminals may be contact terminals with plug-in contactless readers. The combination terminal 126 can include a memory 128, a processor portion 130, a reader module 132, and (as needed) a project interface module, such as a code scanner 134 and/or a radio frequency identification (RFID). Tag reader 136. Items 128, 132, 134, 136 can be coupled to the processor 130. It should be noted that the construction principle of the combination terminal 126 can be applied to other types of terminals, and will be described in detail for illustrative purposes. The reader module 132 can be configured for contact communication with the card or device 102; contactless communication with the card or device 112; reading of the magnetic strip 152, or any combination of two or more of the foregoing (available Different types of readers are provided to interact with different types of cards such as splices, magnetic strips or no splices. The terminals 122, 124, 125, 126 can be connected to one or more processing centers 140, 142, 144 via a computer network 138. Network 138 can include, for example, the Internet or a proprietary network. More than one network can be used to connect different components of the system. The processing center 140, 142, 144 can include, for example, one of the card issuing banks of a payment device. Additional details regarding one particular form of the network will be provided below.

Many different retail or other settings, represented by point of sale 146, 148, can be connected to network 138. In one or more embodiments of the present invention, the various configurations preferably interface with a telecommunications network, such as a virtual private network (VPN), which is thereafter connected to the network. One or more machines. This will be discussed separately below. Each such setup may have one or more terminals. In addition, different types of portable payment devices, terminals, or other components or components may be combined or "mixed and matched" as depicted by the exemplary device of FIG. One or more characteristics.

The portable payment device can facilitate a transaction by a user via a terminal (e.g., 122, 124, 125, 126) of a system such as system 100. Such a device can include a processor, such as processing units 106, 116 discussed above. The device can also include a memory, such as the memory portions 108, 118 discussed above coupled to the processor. Additionally, the device can include a communication module coupled to the processor and configured to interface with a terminal (e.g., one of the terminals 122, 124, 125, 126). The communication module can include, for example, the electrical connectors 110 or antennas 120, along with appropriate circuitry (e.g., the aforementioned oscillators and associated circuitry) that permit interfacing with the terminals via contact or wireless communication. The processor of the apparatus is operative to perform one or more steps of the methods and techniques. The processor can perform such operations via hardware technology and/or under the influence of program instructions for storing an application in one of the memory units, for example.

The portable device can include a body portion. For example, in the case of "smart" cards 102, 112, this may be a stacked plastic body (as discussed above), or a handset chassis and body in the case of a cellular telephone.

It will be appreciated that the terminals 122, 124, 125, 126 are examples of terminal devices for interacting with a payment device of one of the holders. The apparatus can include a processor (eg, processor 130); a memory (eg, memory 128) coupled to the processor; and a communication module (eg, 132) coupled to the processor and configured Interfaced with the portable devices 102, 112, 142. The processor 130 is operative to communicate with a user's portable payment device via the communication module 132. The terminal devices can operate via hardware technology in the processor 130 or by program instructions stored in the memory 128. Such logic may be provided at network 138 from a central location, such as processing center 140, as desired. The aforementioned barcode scanner 134 and/or RFID tag reader 136 may be provided and coupled to the processor to collect, for example, a product identification attribute from a UPC code or RFID tag on one of the purchased products.

The above devices 102, 112 may be contact cards or devices suitable for ISO 7816 or NFC (Near Field Communication) or adjacent cards or devices suitable for ISO 14443. In operation, the card 112 can be touched or tapped at the terminal 124 or 128, and the terminal then transmits the electronic material contactlessly to adjacent IC chips or other wireless devices in the card 112.

One or more of the processing centers 140, 142, 144 may include a repository of, for example, a data repository 154.

Reference should now be made to Fig. 2, which is a block diagram 200 of one of the possible exemplary embodiments of the present invention, and also depicts (via the arrows) data streams in accordance with the exemplary embodiment. As shown at 202, a card or other payment device holder interacts with a terminal, such as a merchant or other card receiver, at a point in the interaction point, the terminal corresponding to, for example, a relative The terminal and point of sale described in Figure 1. The card receiver transmits the transaction information to an acquirer 204, for example, via a network as described in FIG. The merchant may provide metrics such as a stock metering unit (SKU) number, a generic product code (UPC), and/or a national drug code (NDC). "SKU" is the most commonly used for online business and refers to a common term for a unique digital identification of a particular product in inventory or a catalog. This indicator can be provided in an authorization request. A front end processor 206 can be provided between the billing institution 204 and an electronic payment processor 210 (e.g., a virtual private network (VPN) or a third party credit card processor of a credit card company). The front end processor 206 can be located in a wide variety of locations, such as equipment at the acquirer. An example of a suitable front end processor 206 is a MASTERCARD INTERFACE PROCESSOR ^(TM) or MIP ^(TM) processor (trademark of MasterCard International Inc. of Purchase, New York). As will be discussed more fully below, the acquirer 204 should be a separate bidding acquirer.

Of course, those skilled in the art will appreciate that in this context, "processor" 210 means, for example, an entity having a VPN or other network and the like, and "processors" 206, 214 represent a particular one. Hardware.

The acquirer 204 can forward the indicator to a transmission engine 212 via, for example, the front end processor 206 and the electronic payment processor 210. The transport engine is depicted in Figure 2 as a "SKU transport engine," but it should be understood that as discussed herein, it can handle a wide variety of metrics. The engine 212 receives the authorization request and translates the indicator into a form that one of the administrators of the third party manager (TPA) 216 can understand. The translated indicator can be populated into the authorization request, which is then forwarded by the engine 212 to, for example, an administrator of the TPA 216. This transfer can be via electronic payment processor 210. The administrator 216 can be a card issuing bank of, for example, a card used by the consumer, or a party representing such a card issuing bank. In one or more embodiments, the card may be associated with a health insurance account such as a flexible expense account (FSA) or a health insurance savings account (HSA). It is understood that the present invention is not limited to health care applications and can be used whenever it is desired to approve purchases on a project-by-project basis.

Another front end processor 214, such as a MIP ^(TM) , can be located, for example, on a card issuing bank or other administrator 216 device to provide access to the aforementioned VPN of the electronic payment processor 210. Of course, there may be a number of card-issuing banks with similar equipment, and other equipment. Furthermore, it is emphasized that the configuration shown in Figure 2 is purely exemplary in nature. Other approaches may be used to replace, for example, an architecture using one of the front end processors 206, 214 and one of the electronic payment processors 210, or an internet portal configuration. Those skilled in the art will also appreciate that there may be other changes.

The third party manager 216 can match the translated indicator against a database containing, for example, a list of selected items under a given health (or other) plan; individual values can be recognized; and the approved Amount. The approved amount may be provided in a response message returned to the merchant 202 via the reverse path just described as indicated by the turn back arrow. It should be noted that the third party approver may maintain a database of selected option purposes, and the engine 212 may maintain a database for translation.

Those skilled in the art are familiar with front end processors (e.g., front end processors 206, 214) and VPNs (e.g., VPNs of electronic payment processor 210). In a specific example, these front-end processor system 206, 214 (e.g., the note) MIP ^TM processors, and electronic payment processor system 210 of the VPN providing telecommunications network services MASTERCARD BANKNET ^® (MasterCard International Inc.of Purchase, A telecommunications network of the registered trademark of New York.

Figure 3 shows a flow chart 300 of exemplary method steps for electronic payment verification. After the start of step 302, in step 304 (promoting obtaining a step for identifying an indicator of an individual item purchased at an interaction point), an inbound authorization request is made in conjunction with the request. This indicator may include, for example, SKU, UPC, NDC, and the like. Individual items purchased may include products and/or services. The interaction point can be any place where the transaction occurs, such as a physician's office, such as a merchant of a grocery western pharmacy. The flow in FIG. 3 is represented from the perspective of, for example, a transport engine of component 212, and thus the inbound authorization request is from an inbound of acquirer 204. As used herein, "promoting" an action includes performing the action, making the action easier, assisting in the act, or causing the action to be performed. Thus, by way of example and not limitation, instructions that are executed on a processor can facilitate the implementation of an operation by an instruction executed on a remote processor; Appropriate information or instructions for the action.

Step 306 includes facilitating translation of the indicator into a form known to a third party transaction approver, such as the issuing bank 216, to obtain translated metrics. Step 308 includes facilitating transmission of the translated indicator to the third party transaction approver for item-by-item verification of the individual items. The transmission of the translated indicator is combined with a departure authorization request (e.g., departure from engine 212 to third party 216).

Further possible steps include steps 310 and 312. Step 310 includes facilitating receipt of verification data from the third party transaction approver associated with item-by-item verification of individual items. This information may include, for example, a total approved and/or project-by-project approval. The item-by-item verification matches the translated indicator based at least on the control one database. It should be noted that even when only one total approved sum is included in the material, the item is still verified by the issuing bank 216 on a project by item basis. Step 312 includes facilitating delivery of the verification data in a response message routed to the interaction point.

As noted, the verification data may include a total amount of recognized currency reflecting the total price of one of the valid items. The total amount of the approved currency is not greater than the total purchase price of the individual items purchased (as discussed further below, which includes any appropriate taxes). In another aspect, the verification data includes a flag for each individual item, and the flags indicate whether a given item is valid. If necessary, include a total approved amount and a flag.

In step 304, in combination with a separate bidding acquiring institution (a separate bidding acquiring institution has a total amount of an approved currency that is less than the amount in the inbound authorization request, and is returned to a purchase from the item. The inbound authorization request of the merchant's acquirer of a capability) obtains an indicator for identifying the individual items.

Optional step 314 includes storing (e.g., in a data store such as 154) at least the translation indicator and the verification data for auditing.

In one or more embodiments, the third party transaction approver is associated with a core issuing institution of a health insurance card, and the database contains at least one given translation indicator representing whether the health care card is retractable by the issuing authority Instructions for the project. By way of example, a card holder may purchase gauze bandages, aspirin and cigarettes; the first two items will be recoverable, but the cigarettes will not. The user may be prompted to pay for an unapproved item via cash, check, another payment card, or the like. As long as the items contain drugs, the indicators used to identify the items may further include time period supply data (eg, one, thirty, sixty, or ninety days of supply for a given therapy).

Processing continues at step 316.

4 shows a flowchart 400 of an exemplary method that can be implemented by a computer to establish a database useful in facilitating electronic payment verification. At this point, it should be noted that although the method illustrated with respect to Figures 3 and 4 can be implemented by a computer, in one or more exemplary embodiments, it can also include one or more manual steps, or manual and computer assisted A combination of steps. After the start of step 402, step 404 includes facilitating obtaining vendor metrics for identifying individual items (products and/or services) for purchase via pre-registration of a plurality of suppliers (eg, merchants, pharmacies, physicians, etc.) (eg, SKU, UPC, drug code and their analogues), together with the identity and cost of such items. Among a given supplier, at least some of the supplier metrics are different for the same item purchased. That is, by way of example, different SKUs can be used in Smith's pharmacy and Baker's pharmacy for the same package of self-adhesive bandages.

Step 406 includes facilitating the generation of a translation database having a single translated indicator associated with one of each given item, regardless of whether a given supplier has different vendor metrics associated with the given item. That is, the self-adhesive bandage is identified by a single unique (translated) identification item, regardless of the fact that Smith and Baker each use a different identification.

Step 408 includes facilitating storage of the translation database in a form that facilitates easily translating a given supplier indicator into a corresponding translated indicator, wherein the given supplier indicator is associated with one of the given supplier indicators Given the identity of the supplier. That is, the identity of the pharmacy or other supplier of the product and its SKU can be found for the universal identification, so the third party can present an approved/unrecognized decision.

Processing continues at step 410.

For convenience of explanation, not every step in Figures 3 and 4 includes the word "promotion", but it will be appreciated that the method of depicting broadly includes facilitating the indicated actions and their actual performance.

By summarizing and providing additional details, the inbound authorization request discussed above may contain information including the cost per item and the identity of the item. This information may also include sales tax or value added tax (VAT) information for the purpose of summing up the exact amount approved. The cost and tax information does not have to be in the database maintained by the third party approver. The cost of each item does not have to be included in the translation database, but can be passed from the merchant to the authorization request accompanying the indicator. Engine 212. As noted above, the quantity will take effect in the case of prescription and/or over-the-counter (OTC) drugs (ie, a 30-day supply is available for 90 days) and can be passed to the third party for approval in the authorization request. people. The third party will then make decisions at the level of each project based on the information provided in the authorization request. Although the cost of the project does not have to be part of the decision, it can be considered.

It will be appreciated that one or more exemplary embodiments of the present invention may provide one or more advantages; for example, reducing or eliminating the need for a third party approver to maintain multiple data sheets, thereby resulting in faster processing times. In one or more specific embodiments, such reduced processing time can be achieved via the translation database of the invention.

The invention may employ hardware and/or software aspects. Software includes, but is not limited to, firmware, resident software, microcode, and the like. The software may be combined with, for example, a terminal, 122, 124, 125, 126, a front end processor 206, 214, a transmission engine 212 of one or more of a merchant, a card issuing bank, an acquirer, a processor or a credit card company. Or a processing center 140, 142, 144 (with data storage bin 154 as needed). At present, the engine 212 can be advantageously implemented, for example, in a software running on a general purpose computer. The database shown in Figure 4 can also be created using software running on a computer. The firmware can be employed in conjunction with, for example, payment devices like cards 102, 112.

5 is a block diagram of a system 500 in which one or more of one or more aspects or procedures of the present invention may be implemented. As shown in FIG. 5, memory 530 configures the processor 520 (which may correspond to, for example, processor portions 106, 116, 130, processors of components 206 through 214, or centers 140, 142, 144) The processor of the remote host) implements one or more aspects of the methods (e.g., in accordance with Figures 3 and/or 4), steps, and functions (all shown as 580 in Figure 5). Different method steps can be performed by different processors. Memory 530 can be distributed or local and processor 520 can be distributed or singular. The memory 530 can be implemented in an electrical, magnetic or optical memory or any combination of such or other types of storage devices, including memory portions as described above with respect to the cards 102, 112. It should be noted that if a distributed processor is employed, the distributed processors that make up processor 520 typically include their own addressable memory space. It should also be noted that some or all of computer system 500 may be incorporated into a particular application or general purpose integrated circuit. For example, one or more method steps can be implemented in the hardware of an ASIC rather than using a firmware. Display 540 represents a wide variety of possible input/output devices.

System and product details

As is well known in the art, some or all of one or more aspects of the methods and apparatus described herein may be distributed as an article, which itself comprises a computer readable medium having The embodied computer readable code component. The computer readable code component can be operated in conjunction with a computer system to perform all or some of the steps to perform the methods or to produce the devices described herein. The computer readable medium can be a recordable medium (such as a floppy disk, a hard disk drive, a compact disk, an EEPROM, or a memory card) or can be a transmission medium (for example, a network including optical fibers, a global information network, and a cable). Or use time-sharing multiple proximity, code division multiple proximity one wireless channel, or other RF channel). Any known or developed medium can be used that can store information suitable for use by a computer system. The computer readable code component is any mechanism for allowing a computer to read instructions and data, such as magnetic changes on a magnetic medium or height changes on a surface of a disc. The media can be distributed across multiple physical devices (or multiple networks). For example, one device can be a physical memory medium associated with a terminal, and another device can be a physical memory medium associated with a processing center.

The computer systems and servers described herein each include a memory that configures an associated processor to implement the methods, steps, and functions disclosed herein. Such methods, steps, and functions may be implemented by, for example, processing the elements 102, 112, 122, 124, 125, 126, 140, 142, 144, 206 through 214, or by any combination of the foregoing. The memories may be distributed or local and the processors may be distributed or singular. The memories can be implemented as an electrical, magnetic or optical memory, or any combination of these or other types of storage devices. Moreover, the term "memory" should be taken broadly to encompass any information that can be read or written from a single address to an address in an addressable space accessed by an associated processor. Under this definition, information on a network is still in a memory because the associated processor can retrieve the information from the network.

Thus, for example, elements of one or more embodiments of the present invention (such as the aforementioned terminals 122, 124, 125, 126; processing centers 140, 142, 144 having data bins 154; front end processors 206 through 214 or for example The payment devices of the cards 102, 112 can implement the method steps described herein using computer technology with appropriate instructions. By way of further example, a terminal device 122, 124, 125, 126 may include, in particular, a communication module; an antenna coupled to the communication module; a memory; and at least one processor (instead of the antenna and communication) a module that provides appropriate contacts and other components for interrogating, for example, a contact payment device of a contact card, or reading a magnetic strip, coupled to the memory and the communication module and operative to interrogate a contactless payment Device. By way of yet another example, a device for electronic payment verification (eg, engine 212) and/or a device for establishing a database useful in facilitating electronic payment verification can include a memory and be coupled to the At least one processor of the memory. The processor is operative to perform one or more of the method steps described herein (e.g., in Figures 3 and/or 4) or to promote its performance.

Thus, it will be appreciated that one or more embodiments of the present invention can comprise a computer program comprising computer code components adapted to perform the disclosure herein when such a program is run on a computer Any method or one or all of the steps of the claim, and such a program may be embodied in a computer readable medium. In addition, one or more of the present invention The embodiment can include a computer that includes code that causes the computer to implement one or more of the methods or claims disclosed herein, along with one or more device elements or features as depicted and described herein.

Although the exemplary embodiments of the present invention have been described herein with reference to the drawings, it is understood that the invention is not limited to the precise embodiments, and The scope or spirit of the invention.

100,500‧‧‧ system

102, 112, 150‧ ‧ cards

104,114‧‧‧Integrated circuit chip

106,116,130‧‧‧ Processor section

108,118‧‧‧Memory section

110‧‧‧Electrical connector

120‧‧‧Antenna

122‧‧‧Contact terminal

124‧‧‧Wireless terminal

125‧‧‧magnetic strip terminal

126‧‧‧Combined terminal

128,530‧‧‧ memory

132‧‧‧Reader module

134‧‧‧Barcode Scanner

136‧‧‧Radio Frequency Identification Tag Reader

138‧‧‧ computer network

140,142,144‧‧‧Processing Center

146,148‧‧‧ points of sale

152‧‧‧magnetic strip

154‧‧‧ data storage

200‧‧‧ data flow

202‧‧‧Businessmen

204‧‧ ‧ acquiring institution

206,214‧‧‧ front-end processor

210‧‧‧Electronic payment processor

212‧‧‧Transport Engine

216‧‧‧ Third Party Manager

520‧‧‧ processor

540‧‧‧ display

1 shows a generalized example of a payment system in which one of the techniques of the present invention can be implemented; FIG. 2 shows a data flow in an exemplary embodiment of the present invention; FIG. 3 is an exemplary method in accordance with one of the aspects of the present invention. Flowchart; and Figure 4 is a flow diagram of another exemplary method in accordance with one aspect of the present invention; and Figure 5 is a block diagram of an exemplary computer system useful in one or more embodiments of the present invention.

200. . . Data flow

202. . . businessman

204. . . Acquiring institution

206,214. . . Front end processor

210. . . Electronic payment processor

212. . . Transport engine

216. . . Third party manager

Claims (22)

A method for electronic payment verification, comprising the steps of: facilitating, in conjunction with an inbound authorization request, obtaining an indicator for identifying a plurality of individual items purchased at an interaction point; facilitating translation of the indicator into a third party transaction approval a form that a person can understand to obtain a translated indicator; and facilitate transmission of the translated indicator to the third party transaction approver for verifying the individual items on a project-by-project basis, the transmission of the translated indicator being combined埠 Authorization request. The method of claim 1, further comprising the additional step of facilitating receipt of verification data from the third party transaction approver associated with the item-by-item verification for the individual items, the item-by-item verification being based at least on a comparison database And matching the translated indicator; and facilitating delivery of the verification data in a response message routed to the interaction point. The method of claim 2, wherein the verification data includes a total amount of an approved currency reflecting a total price of one of the individual items, the total amount of the recognized currency is not greater than a total purchase price of the individual items purchased . The method of claim 3, wherein the verification data further includes a flag for each of the individual items, the flags indicating whether a given item is valid. The method of claim 2, wherein the verification data includes a flag for each of the individual items, the flags indicating whether the given item is valid for one of the items. The method of claim 2, further comprising the additional step of storing at least the translated indicator and the verification data for auditing. The method of claim 2, wherein: the third party transaction approver is associated with a health care card issuing institution; and the database contains at least one given translated indicator representing whether the health care card is recoverable by the issuing institution An indication of a project. The method of claim 7, wherein the items include at least a drug, and the indicator for identifying the item further comprises time period supply data. The method of claim 1, wherein the indicator for identifying the individual items comprises at least a stock metering unit (SKU) number. The method of claim 1, wherein the indicator for identifying the individual items comprises at least an inventory general product code (UPC). The method of claim 1, wherein the indicator for identifying the individual items comprises at least an inventory National Drug Code (NDC). The method of claim 1, wherein the indicator for identifying the individual items is obtained from a separate bid acquiring institution in conjunction with the inbound authorization request, the separate bid acquiring institution having a less than the inbound authorization request One of the amounts of an approved currency is passed back to a merchant from which one of the items is purchased. A method for establishing a database useful in facilitating electronic payment verification, comprising the steps of facilitating obtaining a purchase for identification by pre-registering a plurality of suppliers Supplier indicators for individual projects, together with the identity and cost of such projects, among the suppliers of such suppliers, for at least some of the suppliers of such suppliers The indicators are not the same; facilitating the generation of a translation database with a single translated indicator for each of the given items associated with the project, regardless of whether the given supplier of the supplier has associated with the project Different vendor metrics for a given project; and facilitating the storage of the translation database in a form that facilitates the easy translation of a given supplier metric into a corresponding translated metric, based on the given supplier metric and associated with One of the suppliers of a given supplier's indicator is a member of a given supplier. The method of claim 13, wherein the indicator for identifying the individual items comprises at least a stock metering unit (SKU) number. The method of claim 13, wherein the indicator for identifying the individual items comprises at least an inventory general product code (UPC). The method of claim 13, wherein the indicator for identifying the individual items comprises at least an inventory National Drug Code (NDC). A computer program product comprising a recordable computer readable storage medium comprising computer readable code for electronic payment verification, the computer program product comprising: computer readable code for facilitating bonding An inbound authorization request to obtain an indicator for identifying a plurality of individual items purchased at an interaction point; A computer readable code for facilitating translation of the indicator into a form known to a third party transaction approver for obtaining translated metrics; and computer readable code for facilitating the translated metric Transfer to the third party transaction approver for verification of the individual items on a project-by-project basis, the transmission of the translated indicator being combined with a departure authorization request. The computer program product of claim 17, further comprising: a computer readable code for facilitating receipt of verification data from the third party transaction approver associated with the item-by-item verification for the individual items, The item-by-item verification matches the translated indicator based at least on the control database; and the computer readable code facilitates delivery of the verification data in a response message routed to the interaction point. A computer program product comprising a recordable computer readable storage medium comprising a computer readable program code, the computer program product comprising: a computer readable code, facilitated by pre-registering a plurality of suppliers Supplier metrics used to identify individual items purchased, together with the identity and cost of such items, among the given suppliers of such suppliers, for at least one of the items purchased for that item, the supplier's indicator is at least Some vendor metrics are different; the computer can read the code to facilitate the generation of a translation database with a single translated indicator associated with each of the given items of the project, regardless of the vendor Whether a given supplier has different supplier metrics for the given project associated with the projects; A computer readable code that facilitates storage of the translation database in a form that facilitates the easy translation of a given supplier metric into a corresponding translated metric, based on the given supplier metric and associated with the given One of the suppliers of the supplier's indicator is a member of a given supplier. An apparatus for electronic payment verification, the apparatus comprising: a memory; and at least one processor coupled to the memory, the processor operative to: facilitate obtaining an inbound authorization request for identification An indicator of a plurality of individual items purchased at an interaction point; facilitating translation of the indicator into a form known to a third party transaction approver to obtain translated indicators; and facilitating transmission of the translated indicator to the third party transaction approval Personnel, in order to verify the individual items on a project-by-project basis, the transmission of the translated indicator is combined with a departure authorization request. The apparatus of claim 20, wherein the processor is further operative to: facilitate receiving, from the third party transaction approver, verification data associated with the item-by-item verification for the individual items, the item-by-item verification being based at least on the comparison one The database matches the translated indicator; and facilitates delivery of the verification data in a response message routed to the interaction point. An apparatus for establishing a database useful in facilitating electronic payment verification, the apparatus comprising: a memory; At least one processor coupled to the memory, the processor operative to: facilitate obtaining, by pre-registering the plurality of suppliers, supplier metrics for identifying individual items of the purchase, along with the identity and cost of the items, Among the given suppliers of such suppliers, at least some of the suppliers' indicators are different for the same item of one of the purchased items; facilitating the generation of each given item associated with the item A translation database of a single translated indicator for a project, regardless of whether a given supplier of the supplier has different supplier metrics for the given project associated with the project; and to promote a given indicator Easily translating into a form corresponding to a translated indicator facilitates storage of the translation database, wherein a given supplier is identified based on the given supplier indicator and one of the given supplier indicators associated with one of the suppliers .