Embedded Electronic Payment System and Integrated Circuit

Abstract

An embedded electronic payment (EEP) system allows various devices and appliances to act as a merchant to accept electronic payments. The EEP system can be formed on an integrated circuit or as a software applet to run on a virtual machine. The integrated chip can be a standard IC, an application specific integrated chip, programmable logic device, or a multiprocessor based microcontroller. The EEP system operates with a standard interface that can be adapted to many applications. As a result, the cost of payment integration is reduced. The reduced cost of inclusion allows electronic payment systems to be applied in systems and devices where cost margins previously prohibited custom electronic payment systems. When the EEP system is included as an integrated chip, the system has improved security and power consumption compared to software solutions.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No. 61/668,960, filed Jul. 6, 2012, which is hereby incorporated by reference.

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

Not Applicable

THE NAMES OF PARTIES TO A JOINT RESEARCH AGREEMENT

Not Applicable

INCORPORATION-BY-REFERENCE OF MATERIAL SUBMITTED ON A COMPACT DISC

Not Applicable

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates to devices and systems including and utilizing Embedded Electronic Payment (EEP) systems.

2. Description of the Related Art

Credit cards as a form of electronic payment processing traditionally involves the following transaction functions associated with a merchant account implementation which heretofore is implemented in software.

Authorization: The cardholder presents the card as payment to the merchant and the merchant submits the transaction to the acquirer (acquiring bank). The acquirer verifies the credit card number, the transaction type and the amount with the issuer (Card-issuing bank) and reserves that amount of the cardholder's credit limit for the merchant. An authorization will generate an approval code, which the merchant stores with the transaction.

Batching: Authorized transactions are stored in “batches”, which are sent to the acquirer. Batches are typically submitted once per day at the end of the business day. If a transaction is not submitted in the batch, the authorization will stay valid for a period determined by the issuer, after which the held amount will be returned to the cardholder's available credit (see authorization hold). Some transactions may be submitted in the batch without prior authorizations; these are either transactions falling under the merchant's floor limit or ones where the authorization was unsuccessful but the merchant still attempts to force the transaction through. (Such may be the case when the cardholder is not present but owes the merchant additional money, such as extending a hotel stay or car rental.)

Clearing and Settlement: The acquirer sends the batch transactions through the credit card association, which debits the issuers for payment and credits the acquirer. Essentially, the issuer pays the acquirer for the transaction.

Funding: Once the acquirer has been paid, the acquirer pays the merchant. The merchant receives the amount totaling the funds in the batch minus either the “discount rate,” “mid-qualified rate”, or “non-qualified rate” which are tiers of fees the merchant pays the acquirer for processing the transactions.

Chargebacks: A chargeback is an event in which money in a merchant account is held due to a dispute relating to the transaction. Chargebacks are typically initiated by the cardholder. In the event of a chargeback, the issuer returns the transaction to the acquirer for resolution. The acquirer then forwards the chargeback to the merchant, who must either accept the chargeback or contest it.

An acquiring bank (or acquirer) is the bank or financial institution that processes credit and or debit card payments for products or services for a merchant. The term acquirer indicates that the bank accepts or acquires credit card payment from the card-issuing banks within an association.

For a software or developer to create software and hardware applications to work with a particular acquirer, the acquirer will require that the application be reviewed and certified before the application can be distributed.

Development of a particular electronic payment system requires significant labor, cost, development time, and certification time. Furthermore, a given electronic payment system is difficult to apply to situations other than the originally-intended application (i.e. inflexible). Different credit card transaction acquirers set different requirements with which a particular electronic payment system may not be compatible. A particular payment system will provide a particular security level that may not be acceptable in other applications. Upgrading a particular electronic payment system may be costly and/or impossible.

Development effort is steep for implementing a payment processing, or merchant account interface. There are number of acquirers: e.g. TSYS, Global Payments, First Data, Paymentech, and Heartland, etc. Each acquirer has its own unique protocol that must be implemented through software code and compiled for a particular platform, e.g. Windows or Android. Acquirers exist for various electronic payment systems, not just credit cards.

In software electronic payment systems, discrete software development efforts are needed for each implementation. Then, each acquirer requires certification and security assessments.

High development costs of software electronic payment systems prevent the inclusion of such solutions as commodities into appliances, computers, phones, etc.

Certification. Each acquirer requires its own certification of a particular electronic payment system. Examples of acquirers requiring specific certifications are TSYS, Global Payments, First Data, Paymentech, and Heartland.

The costs of development prevent the inclusion of electronic payment systems on particular devices that otherwise might be used to receive payments.

Security is a big concern surrounding electronic payments. Software payment applications and utilizing devices are largely implemented on operating systems such as Windows® and Linux with full software stacks. These stacks have interfaces that expose the implementations to hacking, malware, and other intrusions.

BRIEF SUMMARY OF THE INVENTION

The invention encompasses an embedded electronic payment system and an integrated circuit implementing, employing, and enabling an embedded electronic payment system merchant account.

An object of the invention is to provide two solutions for simplifying development of payment processes with particular acquirers. A first solution is to provide a standard transaction protocol module that will implement a standard interface to various participating acquirers. A second solution is to provide a programmable transaction module that can be programmed via a programming interface and an application programming interface (API) to implement a desired specific protocol.

The data that is to be processed is received from a payment instrument. Payment instruments is a term meant to include data sources that deliver account information for a transaction. Examples of payment instruments include credit cards, other payment cards, fobs, mobile wallets, and the like.

A further object of the invention is to reduce development time for adding payment processing to any device. By providing the EEP chip, engineers can add the EEP chip to the device hardware configuration along with interfaces to card readers, security programming, and networks, thereby embedding merchant account payment transaction ability into the device.

A further object of the invention is to encourage inclusion of the electronic payments capability in more appliances by lowering the inclusion cost for payment processing. As discussed, the availability of the EEP chip will reduce the cost to appliance developers. Reduced costs will allow for inclusion in devices with tight pricing margins where large marginal costs of otherwise including payment processing would be prohibitive.

By providing an EEP chip, appliance (i.e. devices generally) manufacturers can add electronic payment acceptance to any appliance with a printed circuit board and standard chip implementation design. Furthermore, because the EEP chip is prequalified by the electronic payment transaction acquirer, the appliance manufacture does not need to have the particular appliance approved by the acquirer. In addition, the EEP chip provides the additional security of using a hardware stack for its encryption and decryption.

For example, a vending machine can be adopted to take credit card payments by incorporating the EEP chip on a circuit board in the vending machine, essentially making the vending machine a merchant. An interface for reading credit card data can be added to the outside of the vending machine and connected to the circuit board to feed transaction data. The vending machine is then connected via a suitable network to the electronic payment transaction acquirer. The EEP chip creates encrypted approval request data to be sent to the acquirer. When the acquirer approves the transaction, the acquirer sends encrypted acquirer transaction data to the EEP chip. The EEP chip decrypts the encrypted acquirer transaction data and approves the transaction. The EEP chip instructs the vending machine to dispense the goods. In this way, a customer can use his credit card to buy the goods. More importantly, the vending machine manufacturer can add the electronic payment functionality with built-in approval by the acquirer, by virtue of using the EEP chip.

A further object of the invention is to simplify the acquirer certification process. Implementing the payment engine in a chip makes the certification process simple. The certification can be provided to the chip. Then, developers of appliances that utilize the certified chip will not need to certify their end appliances; the chip carries the certification.

A further object of the invention is to provide a flexible payment acceptance system. Flexibility is addressed in two ways: either with an industry standard acquiring interface protocol or a programmable one. In a standard acquiring interface protocol, the standard can be designed with built-in flexibility, such as register setting for various values. In the programmable side, the protocol can be fully programmable even as a proprietary protocol. This programmability can also be accomplished in a virtual machine running on an embedded microcontroller.

A further object of the invention is to increase the types of devices that can accept electronic payment. Existing devices can be modified to include the EEP chip in the device so that the device can take payments. Therefore, many different devices can have electronic payment capability built in. Existing devices can be upgraded or re-commissioned to include the EEP chip.

A further object of the invention is to increase the security in devices that accept electronic payments. Embedding the payment layers in an integrated circuit (i.e. chip) is a much more secure implementation than software implementations. The stack in a chip implementation is virtually inaccessible.

A further object of the invention is to reduce to practice the interfaces and protocols required for conducting electronic payments with an acquirer of electronic transactions, to an integrated circuit (IC), for use in embedded applications. This IC, or chip, can be implemented in the circuitry of devices/appliances to allow that device to “take” an electronic payment from a user. For example, a home appliance manufacturer like GENERAL ELECTRIC® could add the EEP chip to the circuitry of its laundry appliances to enable the laundry appliances to accept electronic payment, e.g. credit card payment, with a built-in (i.e. not a separate) device. Another example would be point of sale kiosks where the devices could include EEP Chips embedded in their circuitry for taking electronic payments. Even an automobile could be a merchant and take payments services, songs, maps, fares, etc.

The solution also can be implemented as a design module available to be added to the design of another chip, much like an ALU or memory is a library module that a chip designer can add to an Application Specific Integrated Chip (ASIC). The EEP Chip also can be included in the design of computer-based systems or adapter cards or the like for easy implementation of a merchant account for taking electronic payments.

Today, typically, there are a number of layers of software required for securing, registering, and conducting payment transactions. The process for creating an implementation to allow a merchant's device to transact is very cumbersome, time consuming, and requires many man hours. Processor certification and security validation of each software implementation is tedious and costly. The transaction path is also subject to potential intrusion as it is made up of some open/common interfaces/buses etc., this poses significant security risk and liability that has proven to be costly.

In view of the objects, an apparatus adds embedded electronic payment taking to an appliance. The apparatus includes an integrated circuit with inputs and outputs. The number of physical inputs and outputs can be reduced by utilizing multipurpose input/output ports. The integrated circuit has a first input configured to receive data from a payment instrument, such as credit-card data. A first output is configured to transmit approval-request data to an electronic payment transaction acquirer. A second input is configured to receive acquirer transaction data from the acquirer. A second output configured to transmit customer transaction data. The integrated circuit is programmed to process the payment data received at the first input into approval-request data for processing by the transaction acquirer and to transmit the approval-request data from the first output. The integrated circuit is further programmed to process the transaction data received at the second input into the customer transaction data and to transmit the customer transaction data from the second output.

The integrated circuit can be programmed or designed to process credit-card data into approval-request data for processing by a transaction acquirer. The phrase “programmed or designed” is to include dynamic and static implementations of an integrated circuit.

A further object of the invention is to provide a system with an EEP Chip. The system would enable any EEP-enabled device/appliance to be a standalone access point for taking electronic payments. Examples of potential devices and appliances are cell phones and other wireless devices. This eliminates the requirement for the more typical “heavy” connectivity to a network device or gateway for secondarily conducting the transaction with the acquirer. As shown in FIG. 2, another example is an EEP-enabled map kiosk 400 in the middle of a mountain trail for the purchase of selling hiking maps. The kiosk 400 with EEP is essentially a merchant, with a merchant account, much like any retail store. The kiosk 400 includes a printed circuit board (PCB) 403. A chip with an embedded electronic payment chip is connected to the PCB 403. A card reader 401 is connected to the PCB 403 to provide transaction data. A cellular data interface 404 is connected to the PCB 403 for transmitting approval-request data via a cellular antenna 405 across the world wide web 406 to the acquirer 407. If the transaction is approved by the acquirer 407, approval information is transmitted to the PCB 403, which then triggers the map dispenser 402 to dispense a map. A solar panel 408 is included to power the kiosk 400.

Other features of the invention are set forth in the appended claims.

Although the invention is illustrated and described herein as embodied in an embedded electronic payment system and an integrated chip for electronic payment processing, the invention is not limited to the details shown because various modifications and structural changes may be made without departing from the invention and the equivalents of the claims. However, the construction and method of operation of the invention together with additional objects and advantages thereof will be best understood from the following description of specific embodiments when read in connection with the accompanying drawings.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING

FIG. 1 is a schematic view of an embedded electronic payment system according to the invention.

FIG. 2 is a schematic view of a solar powered map dispenser with an embedded electronic payment system according to the invention.

FIG. 3 is a schematic view of a security element according to the invention.

FIG. 4 is a schematic view showing the encryption and decryption of data in the security element.

DETAILED DESCRIPTION OF THE INVENTION

Embodiments of the invention are described below and are shown in the figures of the drawing.

There are at least four different embodiments of the invention.

First, the embedded electronic payment (EEP) module can be embodied as an integrated circuit (IC) or application specific integrated circuit (ASIC) for use on printed circuit boards (PCB) as part of a device or appliance. Examples of devices and appliances include a personal computer (PC), a washing machine, a vending machine, a television set-top box, a telephone, an entryway access control device, a jukebox, an automobile, a train, an arcade, etc.

Second, the EEP module can be embodied as a design element in a design element library for design into other integrated circuits, e.g. a microcontroller, so that the embedded payment function can be part of that chip.

Third, the EEP module can be embodied as a library element that can be “burned” into a programmable logic device such as those available from Altera or Xilinx, which allow for flexible design of PCBs as required by the over system engineer, as typical where programmable logic is used, even on demand.

Fourth, the EEP module can be embodied as a portable applet (i.e. a single purpose application), such as one to be run in a virtual machine such as JAVA® and the like. In such applets, the embedded electronic payment engine can be loaded into an on-demand run-time engine, e.g. Java Virtual Machine.

The embedded electronic payment functionality can be described using schematics, VHDL, a high level programming language, or any other generic or specific descriptive design-entry means that can be reduced (synthesized, compiled, or interpreted) into the form that is required for any of the above.

VHDL (VHSIC (very-high-speed integrated circuit) hardware description language) is a hardware description language used in electronic design automation to describe digital and mixed-signal systems such as field-programmable gate arrays and integrated circuits.

The above embodiments are different from the traditional “software stack” that is typical of payment applications that are compiled or interpreted software solutions that run from memory on a generic microprocessor-based system, such as a credit card terminal or point of sale (POS) computer.

Security Element

FIGS. 1 and 3 show a preferred embodiment of an embedded electronic payment (EEP) chip 100. The embedded electronic payment chip 100 is a plate of semiconductor material, preferably silicon, with a set of electronic circuits formed in the semiconductor material. The embedded electronic payment chip 100 includes a tamperproof security element 101.

An important component to the EEP chip 100 is the tamperproof Security Element (SE) 101 (SE), which also can be referred to as the security module. The SE 101 performs entitlement control and transaction data encryption and decryption.

Subject to possible standardization of details by payment industry consortia, the security element 101 provides for secure validation of a device's entitlement to transact and secure processing of transactions.

In a preferred embodiment, entitlement control is accomplished by seeding a unique encrypted public key (EPK) 102 into each device's SE 101 at the time of manufacture of the EEP chip 100 itself. In an alternate embodiment, the encrypted public key 102 is programmed into the SE 101 at the time of assembly into an appliance via a secure interface 208. The secure interface 208 is preferably a one-time write interface.

Depending on desired entitlement control, an electronic payment transaction acquirer provides a private key (PVK) 103 to the EEP chip 100. The private key 103 is stored in the security element 101. The private key 103 can decrypt the encrypted public key (EPK) to create a decrypted public key or more-simply a public key (PK). The private key 103 is generated with public key and is kept by the device manufacturer or acquirer. Entitlement messages (EM) determine which transactions the embedded electronic payment chip 100 is entitled to process on behalf of the electronic payment transaction acquirer. For example, the presence and/or absence of particular entitlement messages enable whether the EEP chip 100 will accept debit payments, credit-card payments, or other types of payments, or not. Encrypted entitlement messages (EEM) 105 contain decrypted entitlement keys or more simply Entitlement Keys (EK) 106 and are decrypted in the security element 101 using the decrypted public key 104. A computer program for decrypting entitlement keys (i.e. a decrypter) 107 with the public key 104 is stored in the security element 101. Encrypted Entitlement Messages can be provided by an entitlement server controlled by the electronic payment transaction acquirer at design time or at another time, for example, at a periodic upgrade or transaction time.

The embedded electronic payment chip 100 will encrypt Transaction Data (TD) 109 when authorized according to the entitlement keys (EKs) 106. Examples of typical transaction data include payment account identifiers, transaction amount, terminal identifiers, and the like. Transaction data can be entered, for example, from an attached device such as a credit-card reader, a computer, telephone, smartphone, appliance, or the like. Transaction data can further include approval information such as approvals, denials, and transaction limits.

Yet another layer of encryption is possible (if desired) where the Transaction Data is encrypted with Encrypted Control Words (ECW) 110 that are encrypted themselves by the Entitlement Keys (EK) 106. A computer program for encrypting (i.e. an encrypter) 108 the transaction data with the encrypted control words is stored in the security element 101. Control words are the beginning of the transaction encryption chain, as opposed to an entitlement encryption chain. Control words are used in the encryption of transaction data. Control words are encrypted in the ECW for use later to decrypt the encrypted transaction data.

The relationships between encrypted data and decrypted data are shown in the following functions and is further illustrated in FIG. 4. In the functions x represents a decrypt function, preferably, 3DES or AES, but could be another cryptography algorithm. In cryptography, 3DES, also known as Triple DES, is the common name for the Triple Data Encryption Algorithm (TDEA or Triple DEA) block cipher, which applies the Data Encryption Standard (DES) cipher algorithm three times to each data block. The Advanced Encryption Standard (AES) is a specification for the encryption of electronic data established by the U.S. National Institute of Standards and Technology (NIST) in 2001.

PK=EPK×PVK

EK=EEM×PK

CW=ECW×EK

TD=ET×CW

FIG. 4 shows how data is being encyrpted and decrypted by the security element. An entitlement server 300 connected to the security element provides entitlement keys. Control words 301 are generated from the transactio ndata. Control words 301 are used for transaction encryption 302 of the transaction data. For added security, ECW encryption 303 can be added by encrypting the control words 301 using an entitlement key from an entitlement server 300 to create encrypted entitlement control messages 304. The enctrypted transaction data and/or to encrypted entitlement control messages can be transmitted to a multiplexer 305, which in turn can be connected to a GPIO.

The SE can implement failsafe messages that can kill a rogue device by altering its entitlement.

The EEP chip 100 includes the following additional features. The additional features are exemplary and are not necessarily required in other embodiments. A controller interface 220 receives information regarding addressing of data and timing. The controller interface 220 is comprised of an address bus interface 201 for connecting to an address bus, a data bus interface 202 for connecting to a data bus, a clock/control interface 203 for connecting to a system clock and control signals. A card interface 230 provides interfaces for various payment instrument devices. The card interface 230 includes an EMV PED Interface 204. EMV stands for EMV stands for Europay, MasterCard and Visa, a global standard for inter-operation of integrated circuit cards (IC cards or “chip cards”) and IC card capable point of sale (POS) terminals and automated teller machines (ATMs), for authenticating credit and debit card transactions. The card interfaces 230 include a serial interface 205. The card interface 230 may include other payment interfaces 206. The EEP chip 100 includes a chip power/clock/control 212. The EEP chip 100 has a network interface 240 for sending and/or receiving data from the electronic payment transaction acquirer. The network interface 240 includes a Wi-Fi interface 209, a cellular interface 210, and other network interface 211. The EEP chip 110 includes a General Purpose Input/Output (GPIO) 250, which is a generic pin on the chip 100 whose behavior (including whether it is an input or output pin) can be programmed. The EEP chip 100 includes a CPU/microcontroller 260. The EEP chip 100 includes memory 270, in particular, RAM, ROM, and protocol ROM.

Abbreviations:

ECW=Encrypted Control Words

EEP=Embedded Electronic Payment

EEM=Encrypted Entitle Messages

EK=Entitlement Keys

EM=Entitlement message

EPK=Encrypted Public Key

PK=Public Key

PVK=private key

SE=Security Element or Security Module

TD=Transaction Data

Claims

1. An integrated circuit for processing payment instrument and transaction data into approval-request data that is to be evaluated by a payment transaction acquirer, a processor, or a payment instrument issuer, comprising:

a plate of semiconductor material;

a set of electronic circuits on said plate of semiconductor material, said set of electronic circuits defining a hardware stack of memory and a logic unit for implementing a merchant account protocol required for interacting with the payment transaction acquirer, the payment processor, or the payment instrument issuer;

an input for receiving said payment instrument data, said input being connected to said logic unit and said memory; and

an output for sending approval-request data to the electronic payment transaction acquirer, the payment processor, or the payment instrument issuer, said output being connected to said logic unit and said memory.

2. The integrated circuit according to claim 1, wherein:

said set of circuits further defines a security element including: an encrypted public key stored in said memory; said memory being configured to store a private key sent by the electronic payment transaction acquirer, the payment processor, or the payment instrument issuer, said private key being configured to decrypt said encrypted public key into a decrypted public key; a first logic unit being configured to decrypt said encrypted pubic key with said private key to produce the decrypted public key, said memory being configured to store said decrypted public key; said memory being configured to store an encrypted entitlement message from the payment acquirer; a second logic unit for decrypting said encrypted entitlement message with said decrypted public key to produce a decrypted entitlement message, said memory being configured to store said decrypted entitlement message; said memory being configured to store the payment instrument and transaction data; and a third logic unit for encrypting said payment instrument data with said decrypted entitlement message to create encrypted approval-request data, said memory being configured to store said encrypted approval-request data;

said input for receiving said payment instrument and transaction data, said input being connected to said logic units and said memory; and

an output for sending said encrypted approval-request data to an electronic payment transaction acquirer, a processor, or a payment instrument issuer, said output being connected to said logic units and said memory.

3. The integrated circuit according to claim 2, wherein:

said input receives encrypted acquirer transaction data from the electronic payment transaction acquirer, the processor, or the payment instrument issuer; and

said memory of said security element stores a fourth logic unit for decrypting the encrypted acquirer transaction data into customer transaction data by using said decrypted public key.

4. The integrated circuit according to claim 1, wherein said plate of semiconductor material and said set of electronic circuits are a programmable logic device.

5. The integrated circuit according to claim 4, wherein said programmable logic device is programmable using VHDL.

6. The integrated circuit according to claim 2, further comprising a secure interface for inputting said unique encrypted public key to said memory.

7. The integrated circuit according to claim 6, wherein said secure interface is a one-time write interface.

8. The integrated circuit according to claim 1, wherein said third logic unit encrypts said control words with said entitlement key to form an encrypted control word and said third logic unit utilizes said encrypted word when encrypting said payment instrument data.

9. An appliance for processing electronic payments, comprising a printed circuit board with an interface configured to connect to the integrated circuit according to claim 1;

said interface having an output to be connected to the input of the integrated circuit, said output being further configured to transmit the payment instrument data to the integrated circuit; and

said interface further having an input to be connected to the output of the integrated circuit said input being further configured to transmit the encrypted approval-request data to the electronic payment transaction acquirer, the payment processor, or the payment instrument issuer.

10. The integrated circuit chip according to claim 1, wherein said payment instrument and transaction data is selected from the group consisting of credit card data, payment card data, fob data, memory device data, smartcard data, and mobile wallet data.

11. The integrated circuit according to claim 1, wherein said plate of semiconductor material and said set of electronic circuits form a microprocessor.

12. The integrated circuit according to claim 1, wherein said plate of semiconductor material and said set of electronic circuits form an application specific microcontroller.

13. The integrated circuit according to claim 1, wherein said set of circuits define a controller interface.

14. The integrated circuit according to claim 1, wherein said set of circuits define a payment instrument interface.

15. The integrated circuit according to claim 1, wherein said set of circuits define a general purpose interface.

16. The integrated circuit according to claim 1, wherein said set of circuits define a network interface.

17. A system, comprising:

the integrated circuit according to claim 1; and

a security element external to said integrated circuit and interfaced with the integrated circuit.

18. A method for processing payment instrument and transaction data into approval-request data that is to be evaluated by a payment transaction acquirer, a processor, or a payment instrument issuer, which comprises:

providing the integrated circuit according to claim 1;

receiving the payment instrument and transaction data at said input;

processing said payment instrument and transaction data into said approval request data with said logic unit; and

outputting said approval request data from said output.

19. A method for processing payment instrument and transaction data into approval-request data that is to be evaluated by a payment transaction acquirer, a processor, or a payment instrument issuer, which comprises:

providing the integrated circuit according to claim 2;

receiving the private key;

decrypting said encrypted public key with said first logic unit;

receiving the encrypted entitlement message;

decrypting said encrypted entitlement message with said second logic unit;

receiving the payment instrument data;

encrypting the payment instrument data with said third logic unit; and

transmitting said encrypted approval request data to the payment acquirer.

20. A method for making an integrated circuit for processing payment instrument and transaction data into approval-request data that is to be evaluated by a payment transaction acquirer, a processor, or a payment instrument issuer, which comprises:

writing a first hardware description program for decrypting a public key with a private key that complies with VHDL;

configuring a programmable logic controller to create said first logic unit based on said first hardware description program;

writing a second hardware description program for decrypting an encrypted entitlement message with a decrypted public key that complies with VHDL;

configuring said programmable logic controller to create said second logic unit based on said second hardware description program;

writing a third hardware description program for encrypting payment instrument data with a decrypted entitlement message that complies with VHDL;

configuring a programmable logic controller to create said third logic unit based on said third hardware description program; and

embedding an encrypted public key in said programmable logic controller.

21. The method according to claim 16, wherein said programmable logic controller includes a write-once interface and said encrypted public key is written in said programmable logic controller.