Patent Publication Number: US-2018039985-A1

Title: Apparatus and related method for device communication management for transmission of sensitive data

Description:
FIELD OF THE INVENTION 
     The present invention relates generally to processing transactions and managing devices and, more particularly, to transmission of sensitive data such as in electronic payment transactions. 
     BACKGROUND OF THE INVENTION 
     Electronic payment transactions are ubiquitous. A consumer engages in such transactions in wide variety of environments, such as, self-service kiosks, operator-attended workstations, call-centers, and others. Payment can be initiated via credit card, debit card, check, among others. Various payment devices can be use to process payment. 
     Given the inherit risk of fraud with such transactions, a Payment Card Industry Security Standards Council (“PCI Council’), was formed by major players of the credit card industry. The PCI Council sets forth industry standards for data security standards known as the Payment Card Industry Data Security Standard (PCI DSS) and the Payment Card Industry PIN Transaction Security/Point of Interaction (PCI PTS/POI). These standards include multiple requirements and directives for those who process electronic transactions, particularly in which sensitive data is accessed and maintained and for the devices used in those transactions. 
     With reference now to  FIG. 4 , a typical prior-art system is shown for accepting payment at a point of sale (POS), which is authorized via a payment processor  401 . A vendor will typically have a POS workstation  403  that provides devices (e.g.,  406 ,  407 ,  408 ) though which a payment means of a payer  418  can be captured. Devices  406 ,  407 ,  408  include any of a PIN pad, signature capture, or card reader. The payer  418  will respond to messages  410 ,  412 ,  414 , sent from the application  404 . Any of devices  406 ,  407 ,  408  may be “purchaser activated” or activated by an operator of the POS workstation. 
     Upon successful capture of payer  418  data, devices  406 ,  407 ,  408  format a message  409 ,  411 ,  413  and send said message to workstation  403 . Upon receipt, workstation  403  processes the transaction and sends authorization request message  415  through network  402  to payment processor  401 . 
     In a typical embodiment, the workstation  403 , software  404  and  405 , and network  402  process “sensitive data” that is captured during the transaction such as cardholder data used to complete a payment. Said data may be acquired without encryption. In some embodiments, sensitive data is encrypted by the application  404  in the workstation  403  before transmitting message  415  to network  402 . Alternatively, data may be encrypted by the device  406 ,  407 ,  408 . 
     Payment processor  401  receives the message  415 , validates the data contents, determines the type of message, and processes the authorization request. Payment processor  401  formats a response  416  to message  415  and sends said response message through network  402  to workstation  403 . Workstation  403  displays a message to the operator  417  and sends a completion message  410 ,  412 ,  414  to any of devices  406 ,  407 ,  408 . 
     Peripheral payment devices with communications capability are generally connected to a workstation such as a point of sale (POS) system or personal computer via a USB, RS-232, RS485 or other wired connection. A workstation operator controls the flow of the transaction and hence, operation of the peripheral devices. Additionally, where the payment devices are installed in a self-service system such as a self-checkout, vending or payment kiosk, the peripheral devices are controlled by software in the self-checkout system, vending machine or kiosk and in some embodiments a local server in response to customer actions. Typically, peripheral devices are physically attached to and communicatively part of the local workstation configuration, which sends control commands to and receives data from the peripheral devices. While some devices are capable of running an application, the great majority operate in command/response mode. 
     Payment system software is responsible for managing transaction flow, which can typically involve several interdependent operations. Further, payment system software is responsible for communicating through a local network and so to a remote server for purposes of validating data and authorizing the transaction. Given that “sensitive data” passes through the payment system, its software and the network, the payment system, software, and network are in scope for security audits. 
     Payment system software is a popular point of attack for persons trying to acquire sensitive data or damage information systems. When the payment system and network architecture include general-purpose computers, the vulnerabilities of these computers increase the risk and provide attackers ongoing opportunities. Successful attacks have been mounted against such systems. 
     Where peripheral devices are connected to a local workstation, it is difficult to manage the devices, update their software, forms and other digital assets stored on the devices. It is common for device vendors to use proprietary operating systems, firmware and applications in their devices. This then gives vendors control over the software architecture. Companies, such as retailers that deploy the peripherals cannot maintain the devices on-site. Often the devices must be returned to an authorized repair center or the manufacturer in order to be upgraded. While there are remote device management systems, they require significant changes to the companies&#39; infrastructure and can be costly. Each manufacturer&#39;s system is unique. Manufacturers&#39; device management systems are not compatible and may be mutually exclusive. So users of multiple manufacturers&#39; products would have to support two or more systems or select one system leaving some devices unmanaged. Further, if the company changes devices, the new devices may not be compatible with the existing maintenance system. Since device turnover occurs on a 3 to 5 year basis, it is disruptive and costly to the company. 
     Changes to the payment system software such as operating system patches, may “break” the maintenance system. Application changes intended to meet industry compliance rules are an annual event. Upgrades, feature enhancements, and patches are commonly released on a quarterly schedule. Overall, the burden and cost is so high that the great many of companies decline to use a maintenance system and may forego important software upgrades such as security patches. This makes their payment systems, networks, and devices vulnerable to security weaknesses. There is a need for device maintenance that is vendor agnostic and removes the burden of security and software maintenance. That is, a system that can work with the plurality of different devices from different manufacturers and be remotely managed and upgraded. 
     Device authentication is also challenging in particular when the devices, workstations and communications means vary across the installed population. There have been several successful attacks in which compromised devices were installed by attackers posing as POS support engineers and subsequently used by unsuspecting consumers. Because workstations generally have no means of ensuring authenticity and integrity or correct operational status for the deployed devices, they cannot determine if the devices are legitimate, up-to-date, or even supposed to be installed. The Payments Security Standards Council has released requirements for all devices to be authenticated and tracked by location. It is not reasonable to manually authenticate many hundreds of devices in dozens of locations. There is a need or remote device authentication and tracking. 
     Where end user companies maintain their own communications portal for payment transactions, the systems are subject to attack. Several successful security breaches have leveraged retailers&#39; networks as pathways to their payment infrastructure. A typical attack vector finds access to a company server through a poorly secured connection such as used for remote software troubleshooting and maintenance. The access point may be used by outside vendors and/or company personnel. Once in the company&#39;s internal network, the attacker finds a path to systems that process sensitive data. Since internal systems are considered trusted, the attacker can use the point of entry to search for data and applications that can be compromised. Thus, it remains challenging for companies to maintain security on their payments infrastructure and networks while enabling access for legitimate purposes. 
     It should therefore be appreciated that there remains a need for an alternative approach to electronic transactions that addresses these concerns. 
     SUMMARY OF THE INVENTION 
     Briefly, and in general terms, the present invention provides an apparatus and related method for managing of peripheral devices and communication for transmission of sensitive data, such as, payment transactions in a manner that satisfies security concerns while minimizing maintenance of systems that process sensitive data, which can be achieved by reducing or eliminating direct connections from internal networks to workstations and devices, and using a dedicated secure communications link for updates and processing of all sensitive data. In this manner, the system and related method facilitates device maintenance, reduces maintenance overhead and risk of system compromise. 
     More specifically, in an exemplary embodiment, a device communication management (DCM) apparatus is provided having a first and a second communication ports, a controller, and a non-transitory storage medium containing a set of instructions, to receive an electronic transaction request (such as a payment request) through the first communication port; responsive to the electronic transaction request, format a transaction data capture request; transmit the transaction data capture request through the second communication port; receive transaction data through the second communication port, such that the transaction data is isolated from the first communication port; encrypt a transaction processing request in which the transaction processing request is based on the transaction data; transmit the encrypted transaction processing request through the network communication port; and responsive to a reply to the transaction processing request, transmit a transaction status message through the first communication port. 
     In a detailed aspect of an exemplary embodiment, the DCM apparatus further comprises a housing that retains the first communication port, the second communication port, the network communication port, the controller, and the non-transitory storage medium. 
     In another detailed aspect of an exemplary embodiment, the first communication port is in operative communication with a workstation. The second communication port is in operative communication with a peripheral device. The network communication port is in operative communication with a remote server, wherein the set of instructions isolates transaction data from the workstation. 
     More specifically, in another exemplary embodiment, a method managing device communications includes (a) receiving an update file through the network communication port from the remote server; (b) responsive to the update file, formatting an update message for either a peripheral device or a workstation, in which the first communication port is in operative communication with the workstation and the second communication port is in operative communication with the peripheral device; (c) transmitting the update message to the device through either the first communication port or the second communication, to which the device is connected; (d) receiving an acknowledgement from the device through either the first communication port or the second communication, to which the device is connected; (e) formatting and encrypting a confirmation message; (f) transmitting the encrypted confirmation message through the network communication port to the remote server; and (g) receive an acknowledgement response through the network communication port from the remote server. 
     For purposes of summarizing the invention and the advantages achieved over the prior art, certain advantages of the invention have been described herein. Of course, it is to be understood that not necessarily all such advantages may be achieved in accordance with any particular embodiment of the invention. Thus, for example, those skilled in the art will recognize that the invention may be embodied or carried out in a manner that achieves or optimizes one advantage or group of advantages as taught herein without necessarily achieving other advantages as may be taught or suggested herein. 
     All of these embodiments are intended to be within the scope of the invention herein disclosed. These and other embodiments of the present invention will become readily apparent to those skilled in the art from the following detailed description of the preferred embodiments having reference to the attached figures, the invention not being limited to any particular preferred embodiment disclosed. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Embodiments of the present invention will now be described, by way of example only, with reference to the following drawings in which: 
         FIG. 1  depicts a simplified block diagram of an exemplary system environment in accordance with the present invention. 
         FIG. 2  depicts a simplified block diagram of another example of a system environment in accordance with the present invention. 
         FIG. 3  depicts a simplified block diagram of another example of a system environment in accordance with the present invention, including one configuration of apparatus, devices, kiosk with purchaser/payer and server. 
         FIG. 4  depicts a simplified block diagram of an exemplary system of the prior art. 
         FIG. 5  depicts a block diagram of an apparatus for device communication management in accordance with the present invention, showing major components therein. 
         FIG. 6  depicts an example sequence of the apparatus (e.g.,  103 ,  203 ,  303 ,  1403 ) for registration with the server (e.g.,  101 ,  201 ,  301 ,  1401 ) in a system environment in accordance with the present invention, such as  FIGS. 1-3 . 
         FIG. 7  depicts an example sequence of the apparatus (e.g.,  103 ,  203 ,  303 ,  1403 ) for device identification (e.g., devices  105 - 107 ,  205 - 207 ,  305 - 307 ,  1405 - 1407 ) in a system environment in accordance with the present invention, such as  FIGS. 1-3 . 
         FIG. 8  depicts an example sequence of a card present transaction with an attended workstation in a system environment in accordance with the present invention. 
         FIG. 9  depicts an example sequence of a card present transaction communication sequence with an unattended kiosk in a system environment in accordance with the present invention, such as  FIG. 3 . 
         FIG. 10  depicts an example sequence of a card not present transaction with an attended call center workstation in a system environment in accordance with the present invention. 
         FIG. 11  depicts an example sequence of a card present transaction without a local workstation connection and having local device and remote server control in a system environment in accordance with the present invention. 
         FIG. 12  depicts an example sequence of a card present transaction without a local workstation connection and having local device control in a system environment in accordance with the present invention. 
         FIG. 13  depicts an example sequence of a card present transaction without a local workstation connection and having remote server control in a system environment in accordance with the present invention. 
         FIG. 14  depicts a simplified block diagram of another example of a system environment in accordance with the present invention. 
     
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     Referring now to the drawings, and particularly  FIG. 1 , there is shown an exemplary system environment for electronic transactions (such as payment authorizations) in accordance with the present invention. The system includes an apparatus  103  for device communication management installed between peripheral devices  105 ,  106 ,  107 , and workstation  104 . Apparatus further is communicatively connected to the Internet  102 , which gives access to a server  101 . Workstation  101  is communicatively linked to a private network, which gives access to server  121 . Server  101  is communicatively connected to private network  118 , which gives access to a transaction processor  119 . 
     The apparatus  103  routes communication among entities based on parameters in said communication, processing state of apparatus  103  and of the sending and receiving entities, and software instructions executing in apparatus  103 . Communications such as requests for status can be sent from server  101  through apparatus  103  to any of devices  105 ,  106 ,  107 , and workstation  104 . The response from the queried entity is returned to apparatus  103  and a response to server  101  is formatted and sent. Apparatus  103  may independently communicate such as status query, update request, software update, and parameter update with devices  105 ,  106 ,  107 , server  101 , and workstation  104 . 
     Exemplary Embodiment of System Environment Having POS Workstation 
     With reference now to  FIG. 2 , there is shown another exemplary system environment for electronic payment transactions in accordance with the present invention. The system includes a device communication manager (DCM) apparatus  203 , in accordance with the present invention, is installed between peripheral devices  205 ,  206 ,  207 , workstation  204  and server  201  in order to isolate workstation environment from transaction data, device operation and device management. Apparatus  203  further isolates from transaction data the network to which workstation  204  is connected. 
     The apparatus  203  communicates through an Internet connection with server  201  and through USB or RS232 connections communicates with workstation  204  and devices  205 ,  206  and  207 . In the example, the Internet connection  202  can be wired or wireless Ethernet or other connection type or protocol. Communication between apparatus  203  and server  201  can be via a private network or other network such as cellular service. Workstation  204  is a computing platform such as a POS terminal, a PC, a tablet, a self-checkout machine, kiosk, or any other computing system. Devices  205 ,  206 ,  207  may be a such as multi-function POS device, PIN pad, card reader, signature capture device, printer, check scanner, or other peripheral used in a transaction processing system. Apparatus  203  is configured to execute software comprising an operating system, a plurality of applications, communication port management software, and device drivers. 
     The workstation  204  sends a request  208  to apparatus  203  to initiate a transaction. The request includes data necessary for software executing in apparatus  203  to initiate the transaction includes such as an amount due, items and/or services identifiers, merchant ID, workstation ID, date and time. On receipt of a valid request, apparatus  203  formats a message  209 ,  211 , or  213  to be sent to a peripheral device  205 ,  206 , or  207 . The target device receives the message and performs interactions with a payer  224  to capture additional data. The additional data comprises data such as payment credit card data from payer  224 , personal identification number (PIN), electronic signature, acknowledgement of the transaction amount, payer identification data, and responses to marketing queries. The payer  224  may interact with peripheral device  205 ,  206 , or  207  which will capture and store data prior to receipt of a message  209 ,  211 , or  213 . Upon completion of the capture of the additional data, the device formats a message  210 ,  212 ,  214  to be sent to apparatus  203 . The message or data therein may be encrypted. Data specific to the device such as device ID, date, time, and other data needed to manage the device or process the transaction may be included in the message. One or more additional messages may be sent from apparatus  103  to device  205 ,  206 , or  207  to acquire additional data and transmit it to apparatus  103 . 
     On receipt of the device message  210 ,  212 ,  214 , apparatus  203  parses the message and validates the data, and determines if the transaction can continue. At this time, if there is any reason why the transaction cannot continue, apparatus  203  may respond to workstation  204  with an error condition. Given the transaction can continue, apparatus  203  formats a server message  216 . Said message comprises data such as payment data, authentication data, apparatus ID, apparatus firmware revision, and other data necessary for the transaction. The message or portions thereof may be encrypted by apparatus  203  including but not limited to, individual data elements, multiple data elements, and the entire message. Apparatus  203  sends the message  216  to server  201 . A protocol such as PCT, SSL or TLS may be used for message security. Upon receipt, server  201  parses the message  216 , determines source and type of message, and processes the message to facilitate completion of the transaction. Server  201  may decrypt the message or portions thereof. Processing may include authentication using any of data from the sending apparatus  203 , any of devices  205 ,  206 ,  207 , payer  224  provided data used in the transaction, and of workstation  204 . 
     Server  201  may perform local processing such as querying and/or updating  220  a database  221 , verifying identifying data from any of apparatus  203 , workstation  204  and/or devices  205 ,  206 ,  207 , authorization, fraud checking, and other related actions. If server  201  determines there is any reason to prevent the transaction from being further processed, server  201  may respond to apparatus  203  with an error condition message and log the error condition and transaction data to database  221 . Additionally server  201  may forward all or a portion of the message  218  to one or more entities such as a payment processor  223  or other third parties via network  222 . Processor  223  receives message  218 , and takes further action based on the contents of the message  218 . Said actions will include such as verifying the message  218  data integrity, verifying sender identity, verifying merchant identity data, executing payment authorization, fraud checking, and database updates. Upon completion of processing the message  218 , Processor  223  responds with a result message  219 . 
     Server  201  receives message  219 , and processes the message. Server  201  may decrypt all or portions of message  219  prior to processing said message. Server  201  updates database  221  based on the contents of message  219 . Server  201  formats a response  217  to apparatus&#39;s  203  message  216 . The message  217  and portions thereof may be encrypted by server  201  including but not limited to, individual data elements, multiple data elements, and the entire message. Server  201  may add data to the message  219  including but not limited to the transaction processing result, configuration data  519  for any of apparatus  203 , workstation  204 , or devices  205 ,  206 ,  207 , and other data needed to complete the transaction. Server  201  sends the response message  217  to apparatus  203 . 
     Upon receipt of message  217 , apparatus  203  processes the message and determines the transaction processing result. Apparatus  203  formats a message  215  for workstation  204  and any of the devices  205 ,  206 ,  207  and transmits the one or more messages  209 ,  211 ,  213 ,  215 . Upon completion of the transaction, apparatus  203  resumes “listening mode” and waits for a message from any of server  201 , workstation  204 , or devices  205 ,  206 ,  207 . 
     Exemplary Embodiment of Kiosk System Environment 
     With reference now to  FIG. 3 , a system environment is shown, depicting an apparatus  303 , in accordance with the present invention, installed between peripheral devices  305 ,  306 ,  307 , a kiosk  304 , and a server  301  in order to isolate kiosk environment from transaction data, device operation and device management. The apparatus  303  further isolates the network to which kiosk  304  (aka, unattended workstation) is connected from transaction data. 
     The apparatus  303  communicates through an Internet connection with server  301  and through such as USB or RS232 connections communicates with kiosk  304  and devices  305 ,  306  and  307 . In the exemplary embodiment, the Internet connection  302  can be wired or wireless Ethernet or other connection type or protocol such as a private or cellular network. The apparatus  303  is in operative communication with kiosk  304 . 
     In the exemplary embodiment, the kiosk  304  is a computing platform such as a POS terminal, PC, special-built computing platform, self-checkout, or any other computing system. Devices  305 ,  306 ,  307  may be any such as multi-function POS device, PIN pad, card reader, signature capture device, printer, check scanner, or other peripheral used in a transaction processing system. Apparatus  303  is configured to execute software comprising an operating system, a plurality of applications, communication port management software, and device drivers. 
     With continued reference to  FIG. 3 , a payer  324  interacts with kiosk  304  to select items and/or services to purchase. Kiosk  304  sends a request  308  to apparatus  303  to initiate a payment transaction based on payer&#39;s  324  selection. The request includes data necessary for software executing in apparatus  303  to initiate the transaction and includes such as an amount due, items and/or services identifiers, merchant ID, kiosk ID, payer ID, date and time. On receipt of a valid request, apparatus  303  formats a message  309 ,  311 , or  313  to be sent to peripheral device  305 ,  306 , or  307 . The target device receives the message and performs interactions with a payer  324  to capture additional data. The additional data comprises data such as payment credit card data, personal identification number (PIN), electronic signature, acknowledgement of the transaction amount, and payer&#39;s  324  responses to marketing or other queries. The payer  324  may interact with peripheral device  305 ,  306 , or  307  which will capture and store data prior to receipt of a message  309 ,  311 , or  313 . Upon completion of the capture of the additional data, the device  305 ,  306 , or  307  formats a message  310 ,  312 ,  314  to be sent to apparatus  303 . The message or data therein may be encrypted. Data specific to the device such as device ID, date, time, and other data needed to manage the device or process the transaction may be included in the message. 
     On receipt of the device message  310 ,  312 ,  314 , apparatus  303  parses the message and validates the data, and determines if the transaction can continue. At this time, if there is any reason why the transaction cannot continue, apparatus  303  may respond to kiosk  304  with an error condition and log the error condition and transaction data to database  321 . Given the transaction can continue, apparatus  303  formats a server message  316 . Said message comprises payment data, authentication data, apparatus ID, apparatus firmware revision, and other data necessary for the transaction. The message or portions thereof may be encrypted by apparatus  303  including but not limited to, individual data elements, multiple data elements, and the entire message. Apparatus  303  sends the message  316  to server  301 . A protocol such as PCT, SSL or TLS may be used for message security. Upon receipt, server  301  parses the message  316 , determines source and type of message, and processes the message to facilitate completion of the transaction. Server  301  may decrypt the message or portions thereof. Processing may include authentication of any of data from the sending apparatus  303 , any of devices  305 ,  306 ,  307  used in the transaction, and kiosk  304 . 
     Server  301  may perform local processing such as querying and/or updating a database  321 , verifying identifying data from any of apparatus  303  kiosk  301  and/or devices  305 ,  306 ,  307 , authorization, fraud checking, and other related actions. If server  301  determines there is any reason to prevent the transaction from being further processed, server  301  may respond to apparatus  303  with an error condition message. Additionally server  301  may forward all or a portion of the message  318  to one or more entities such as a payment processor  323  or other third parties via network  322 . Processor  323  receives message  318 , and takes further action based on the contents of the message  318 . Said actions will include such as verifying the message  318  data integrity, verifying sender identity, verifying merchant identity data, executing payment authorization, fraud checking, and database updates. Upon completion of processing the message  318 , Processor  323  responds with a result message  319 . 
     Server  301  receives message  319 , and processes the message. Server  301  may decrypt all or portions of message  319  prior to processing said message. Server  301  updates database  321  based on the contents of message  319 . Server  301  formats a response  317  to apparatus&#39;s  303  message  316 . The message  317  and portions thereof may be encrypted by server  301  including but not limited to, individual data elements, multiple data elements, and the entire message. Server  301  may add data to the message  319  including but not limited to the transaction processing result, configuration data  519  for any of apparatus  303 , kiosk  304 , or devices  305 ,  306 ,  307 , and other data needed to complete the transaction. Server  301  sends the response message  317  to apparatus  303 . 
     Upon receipt of message  317 , apparatus  303  processes the message and determines the transaction processing result. Apparatus formats a message  315  for kiosk  304  and any of the devices  305 ,  306 ,  307  and transmits the one or more messages  309 ,  311 ,  313 ,  315 . Upon completion of the transaction, apparatus  303  resumes “listening mode” and waits for a message from any of server  301 , kiosk  304 , or devices  305 ,  306 ,  307 . 
     Exemplary Apparatus Design 
     With reference now to  FIG. 5 , an exemplary embodiment of an apparatus (e.g.,  103 ,  203 ,  303 ), in accordance with the present invention, usable with the system environments depicted in  FIGS. 1-3 , among others. For example,  FIG. 2  depicts a system environment in which apparatus  203  is used in a transactional environment such as those that accept credit card payments. Apparatus  103 ,  203 ,  303  comprises a housing  518  which encloses a processor  500  (e.g., controller) with a secure area  506 , memory  501  (e.g., non-transitory storage medium), USB ports  508 ,  509 ,  510 , RS232 port  511 , and Ethernet port  512 , wireless communication module  507 , on/off switch  513 , reset switch  514 , LED  515 , SD Card slot  516 , USB Hub  517 . The processor  500  (e.g., controller) is configured to execute an operating system and/or firmware  502 , a plurality of applications  503  and device drivers  504 . Secure area  506  stores sensitive data and firmware such as encryption keys, executable encryption algorithm code, and configuration data  519 . 
     Input and output of data and messages via USB ports  508 ,  509 ,  510 , RS232 port  511 , Ethernet port  512 , and wireless communication module  507  are controlled by a controller, e.g., software executing on processor  500 . Protocols, communication speed and other configurable elements are selected based on the capabilities of the attached devices, the protocols and device drivers available to the OS and firmware  502 , and capabilities of the application(s)  503 . Communication to or from any port is processed by the processor  500  (e.g., controller) and the logic executing in Firmware/OS  502  and/or applications  503 . 
     Messages, software executables, configuration data  519 , operational status, logs, and other information may be temporarily stored in memory  501  or alternatively on an optional SD card inserted in slot  516 . In some embodiments, additional memory in the SD card form factor may be desirable to hold files or updates to the applications  503  or Firmware/OS  502 . In other embodiments, the files may be intended for an external device  205 ,  206 ,  207 , kiosk  304 , or workstation  204 . Upon receipt, the files could be temporarily stored in memory  501 , or on the SD card in slot  516 . Temporary storage would enable the applications  503  to authenticate such files, check for errors introduced by communication failure, buffer the file for later transmission to the target entity, reformat the file and reconfigure the file in a different protocol. Pressing the On/Off switch  513  powers up and powers off apparatus  203 . In an exemplary embodiment, the reset switch  514  causes the apparatus to return to a known, stable state. For example, if the application has been corrupted pressing the reset switch  514  would cause apparatus to erase the application and return to a “factory state.” The Firmware/OS  503  would then communicate with server  201  and request a new file. Server  201  would respond to the request and send the appropriate file to reinstate the operational mode of apparatus  203 . The LED  515  shows status of apparatus  203  and can indicate several operational states. Among the operational states are powered off, operating normally, error condition, registering, authenticating, installing, and idle state. In other embodiments, the LED  215  could be used to diagnose error conditions by flashing colors and/or sequences and/or durations that can be mapped to documentation. 
     With continued reference to  FIG. 5 , processor  500  (e.g., controller) may support features such as data and code authenticity and integrity, cryptographic acceleration and anti-tamper protections. Processor  500  and secure area  506  monitor the security of apparatus  203 , authenticity of executable code, configuration, and message authenticity and integrity. Security monitoring may include anti-tamper mechanisms such as detecting physical penetration, housing breach, temperature variation, power variation, and software attacks. In the event that a security violation is detected, the processor  500  could initiate self-protective action such as erasing sensitive data and applications. Erasure would render apparatus  203  unusable. Reinstating apparatus  203  to an operational state following erasure would be performed only by an authorized entity employing strong security measures. 
     Exemplary Method for Apparatus Registration 
     With reference now to  FIG. 6 , an exemplary flowchart is provided, depicting the process flow for registering the apparatus (e.g.,  103 ,  203 ,  303 ) with the server (e.g.,  101 ,  201 ,  301 ) in a system environment in accordance with the present invention, such as  FIGS. 1-3 . More particularly, the steps enable the apparatus to register with server validate workstation application and devices. Error conditions can result in the Apparatus unit being marked down with an alert status. 
     The process can initiate at step  601 , in which the apparatus powers up and executes its boot up software. In the exemplary embodiment, the steps are performed as follows: 
     
       
         
           
               
               
             
               
                   
               
               
                 Step 
                 Task 
               
               
                   
               
             
            
               
                 601. 
                 Apparatus (103) powers up and executes its boot up software (502) 
               
               
                 602. 
                 Boot Loader (502) executes from secure memory 
               
               
                 603. 
                 Boot Loader (502) and security firmware (502) validate hardware and software 
               
               
                 604. 
                 Operating (502) system executes and the Core Application (503) starts 
               
               
                 605. 
                 Core Application (503) Executes and begins system status checks 
               
               
                 606. 
                 Core Application (503) checks system status and gathers data 
               
               
                 607. 
                 Ethernet communication (504) startup and Core Application (503) connects to Server 
               
               
                   
                 (101) 
               
               
                 608. 
                 Core Application (503) sends an initialization message with its credentials and system 
               
               
                   
                 status to server (101) 
               
               
                 609. 
                 Server (101) receives initialization message 
               
               
                 610. 
                 Server (101) updates device management database (221) using data received from the 
               
               
                   
                 Core Application (503) 
               
               
                 611. 
                 Server validates Apparatus status and builds an authentication response 
               
               
                 612. 
                 Server (101) checks Apparatus (103) software versions and configuration data (519) 
               
               
                 613. 
                 Server (101) builds response to Apparatus (103) including any updates needed to OS 
               
               
                   
                 (502), Applications (503), configuration files (519), security data 
               
               
                 614. 
                 Server (101) sends response to Apparatus (103) 
               
               
                 615. 
                 Apparatus Core Application (503) receives server (101) response 
               
               
                 616. 
                 Core Application (503) validates server (101) credentials and the updates received 
               
               
                   
                 a. If successful, Apparatus (103) ACKs server (101) and server and Apparatus unit are 
               
               
                   
                 mutually authenticated 
               
               
                 617. 
                 Core Application (503) installs Apparatus (103) updates as needed 
               
               
                 618. 
                 Apparatus (103) completes updates and reboots 
               
               
                 619. 
                 Apparatus (103) executes boot process, starts OS (502) and Core Application (503). 
               
               
                   
                 Core Application executes Interface Application (503) 
               
               
                 620. 
                 Interface Application (503) is in Ready Mode 
               
               
                   
               
            
           
         
       
     
     The above-mentioned steps are provided as exemplary. Steps can be eliminated, combined, or added without departing from the invention. Moreover, in certain embodiments, steps can be performed in a different order without departing from the invention. 
     Exemplary Method for Device Identification 
     With reference now to  FIG. 7 , an exemplary flowchart is provided, depicting an exemplary sequence of the apparatus (e.g.,  103 ,  203 ,  303 ) for device identification (e.g., devices  105 - 107 ,  205 - 207 ,  305 - 307 ) in a system environment in accordance with the present invention, such as  FIGS. 1-3 . In the exemplary embodiment, the steps are performed as follows: 
     
       
         
           
               
               
             
               
                   
               
               
                 Step 
                 Task 
               
               
                   
               
             
            
               
                 701. 
                 Apparatus (103) completes Boot Up and Registration Process including any updates 
               
               
                   
                 from the Server.101) 
               
               
                 702. 
                 Core Application (503) reads configuration file (519) to determine expected devices 
               
               
                   
                 (105, 106, 107) and workstation (104) connections. 
               
               
                 703. 
                 Apparatus Core Application (503) queries devices (ports 508, 509, 510, 511) to 
               
               
                   
                 identify the attached devices based on server (101) supplied device configuration data 
               
               
                   
                 (519) stored in Apparatus (103) memory (501) 
               
               
                 704. 
                 Devices (105, 106, 107) (respond with serial number, and other data such as firmware 
               
               
                   
                 revision. 
               
               
                 705. 
                 Apparatus (103) validates device (105, 106, 107) responses (110, 112, 114) and logs 
               
               
                   
                 results to memory (501) 
               
               
                   
                 a. Any port (508, 509, 510, 511) that times out, Core Application (503) flags as 
               
               
                   
                 unresponsive 
               
               
                 706. 
                 Apparatus (103) validates workstation (104) application and logs results to memory 
               
               
                   
                 (501) 
               
               
                   
                 a. Apparatus (103) and workstation (104) are mutually authenticated 
               
               
                 707. 
                 Core Application (503) connects to Server.(101) 
               
               
                 708. 
                 Apparatus (103) builds server (101) message including workstation (104) and device 
               
               
                   
                 (105, 106, 107) data and sends to server (101) 
               
               
                 709. 
                 Server (101) receives Apparatus (103) message, updates the database (221) with 
               
               
                   
                 workstation and device data and responds to Apparatus (103). 
               
               
                   
                 a. Server (101) application checks the database (221) for Workstation (103) and 
               
               
                   
                 Device (105, 106, 107) software for update. Device (105, 106, 107) forms and 
               
               
                   
                 applications are also checked for possible update. If needed, the update(s) can be 
               
               
                   
                 pushed to Devices (105, 106, 107) via Apparatus (103) or scheduled for another 
               
               
                   
                 time. It is likely that updates will not be done during the clients&#39; business hours 
               
               
                   
                 unless they are necessary for operation. 
               
               
                 710. 
                 Apparatus (103) is now ready to process 
               
               
                   
               
            
           
         
       
     
     The above assumes no errors occur. The user will see the status LED cycle from off to solid green. If an error occurs, the status LED will indicate the first error condition it encounters. Setup will halt at that error. If mutual authentication with workstation, kiosk, or any of devices fails in any part, apparatus NAKs the other entity and notifies server of the error condition. If server mutual authentication fails in any part, server or apparatus will NAK. Any failure will cause apparatus unit to be marked in alert state in the server database. 
     The above-mentioned steps are provided as exemplary. Steps can be eliminated, combined, or added without departing from the invention. Moreover, in certain embodiments, steps can be performed in a different order without departing from the invention. 
     Exemplary Method for Workstation Card Present Flow with Operator 
     With reference now to  FIG. 8 , an exemplary flowchart is provided, for an example sequence of a card present transaction with an attended workstation in a system environment in accordance with the present invention. the exemplary embodiment, the steps are performed as follows: 
     
       
         
           
               
               
             
               
                   
               
               
                 Step 
                 Task 
               
               
                   
               
             
            
               
                 801. 
                 Operator (225) enters the amount of the payment and any other non-sensitive data on 
               
               
                   
                 workstation (204). Alternatively, the client systems may auto-fill the data. A 
               
               
                   
                 payment transaction is initiated by operator (225) on the local workstation (203) 
               
               
                   
                 (click the [Pay Now] button) 
               
               
                 802. 
                 Workstation (203) application (503) (may be an executable program or a browser 
               
               
                   
                 page) sends a “start payment transaction request” (to apparatus. Data may include the 
               
               
                   
                 payment amount, items and/or services identifiers, merchant ID, etc. The message 
               
               
                   
                 may include the ID of the device to be used for payer&#39;s (224) payment data entry or 
               
               
                   
                 the current default port may be used. 
               
               
                 803. 
                 Apparatus (203) ACKs (215) the request 
               
               
                 804. 
                 Apparatus (203) application (503) formats the first device command and sends the 
               
               
                   
                 message (209, 211, 213) to the device (205, 206, 207). 
               
               
                 805. 
                 The device (205, 206, 207) enters encrypting data capture mode and captures payer 
               
               
                   
                 (224) data such as credit card number, expiry date, and CVV. Other data may be 
               
               
                   
                 requested for address verification. (Device may be preconfigured for the data entry 
               
               
                   
                 sequence or respond to commands from the apparatus.) 
               
               
                 806. 
                 The payer (224) provides payment card information with swipe, card insert, card tap, 
               
               
                   
                 and keypad entry as needed. 
               
               
                 807. 
                 Device (205, 206, 207) packages the payer (224) data and device data and formats it 
               
               
                   
                 for transmission to apparatus. 
               
               
                 808. 
                 Device (205, 206, 207) encrypts the data and sends it to apparatus (203). 
               
               
                 809. 
                 Apparatus (203) receives the payer (224) data from device (205, 206, 207), combines 
               
               
                   
                 it with workstation (204) data and apparatus (203) data to build a server (201) 
               
               
                   
                 message. Apparatus (203) formats the header and trailer, adds authentication data. 
               
               
                 810. 
                 Apparatus (203) sends transaction message (216) to the server (201) and a status 
               
               
                   
                 message to workstation (204) application. Workstation (204) application may display 
               
               
                   
                 the status for the operator (225). 
               
               
                 811. 
                 Server (201) receives the payment data package (216), authenticates it and extracts 
               
               
                   
                 the payload. 
               
               
                 812. 
                 Server (201) updates the transaction and device databases (221) (Transaction 
               
               
                   
                 date/time, device ID, merchant ID, items and/or services identifiers, etc. No sensitive 
               
               
                   
                 data retained) 
               
               
                 813. 
                 Server (201) processes the payment transaction (216) (e.g. an authorization)—sends 
               
               
                   
                 the authorization request (218) to the payment network (222). 
               
               
                 814. 
                 Server (201) receives the authorization response (219). 
               
               
                 815. 
                 Server (201) builds the message and sends the authorization results (217) to 
               
               
                   
                 Apparatus (203). 
               
               
                 816. 
                 Apparatus (203) gets the response (217) from server (201), authenticates, extracts 
               
               
                   
                 payload, ASKS server (201) 
               
               
                 817. 
                 Apparatus (203) sends transaction result message (215) to workstation (204) 
               
               
                   
                 application (Status of transaction, authorization code, etc. May include an error code 
               
               
                   
                 if the transaction failed to authorize.) 
               
               
                 818. 
                 Apparatus (203) sends completion message to device(s) (205, 206, 207) and returns to 
               
               
                   
                 listener mode. 
               
               
                   
               
            
           
         
       
     
     The above-mentioned steps are provided as exemplary. Steps can be eliminated, combined, or added without departing from the invention. Moreover, in certain embodiments, steps can be performed in a different order without departing from the invention. 
     Exemplary Method for Kiosk Card Present Flow 
     With reference now to  FIG. 9 , an exemplary flowchart is provided, for an example sequence of a card present transaction communication sequence with an unattended kiosk in a system environment in accordance with the present invention, such as  FIG. 3 . In the exemplary embodiment, the steps are performed as follows: 
     
       
         
           
               
               
             
               
                   
               
               
                 Step 
                 Task 
               
               
                   
               
             
            
               
                 900. 
                 Payer (324) selects services or products depicted or listed on a display or other 
               
               
                   
                 selection mechanism such as entering an item code on a keypad or using a touch 
               
               
                   
                 screen on kiosk (304). 
               
               
                 901. 
                 Kiosk (304) application informs payer (324) of the total amount of the transaction. 
               
               
                   
                 Payer (324) provides electronic payment data such as a credit card swipe. 
               
               
                 902. 
                 Kiosk (304) application (may be an executable program or a browser page) sends a 
               
               
                   
                 “start payment request” (308) to apparatus (303). Data may include the payment 
               
               
                   
                 amount, merchant ID, payer (324) data, and other transaction data. The message may 
               
               
                   
                 include the ID of the device (305, 306, 307) used for payer&#39;s (324) payment data 
               
               
                   
                 entry or the current default port may be used. 
               
               
                 903. 
                 Apparatus (303) ACKs (315) the request (308) 
               
               
                 904. 
                 Apparatus (303) application formats the first device command and sends the message 
               
               
                   
                 (309, 311, 313) to the data capture device (305, 306, 307). 
               
               
                 905. 
                 The device (305, 306, 307) enters encrypting entry mode. Kiosk (304) instructs the 
               
               
                   
                 payer (324) to perform the payment data capture event such as inserting a credit card. 
               
               
                 906. 
                 The payer (324) provides payment card information. 
               
               
                 907. 
                 The device (305, 306, 307) captures and validates the payer&#39;s (324) payment data. 
               
               
                 908. 
                 The device (305, 306, 307) encrypts the data in whole or in part and sends (310, 312, 
               
               
                   
                 314) it to apparatus (303). 
               
               
                 909. 
                 Apparatus (303) receives the device data message, formats a server (301) message 
               
               
                   
                 including such as a header and trailer, authentication data, payment data, items and/or 
               
               
                   
                 services identifiers, kiosk ID, merchant ID, apparatus ID, date and time. 
               
               
                 910. 
                 Apparatus (303) sends the message (316) to server (301) and a status message (315) 
               
               
                   
                 to kiosk (304) application. Kiosk (304) application may display the status for the 
               
               
                   
                 payer (324). 
               
               
                 911. 
                 Server (301) receives the payment data package, authenticates it and extracts the 
               
               
                   
                 payload. 
               
               
                 912. 
                 Server (301) updates the transaction and device databases (321) (Transaction 
               
               
                   
                 date/time, etc. No sensitive data is retained.) 
               
               
                 913. 
                 Server (301) processes the payment transaction (e.g. an authorization)—sends the 
               
               
                   
                 authorization request (318) to the payment network (322). 
               
               
                 914. 
                 Server (301) receives the authorization response.(319) 
               
               
                 915. 
                 Server (301) builds the authorization results message (317) and sends it to 
               
               
                   
                 apparatus.(303) 
               
               
                 916. 
                 Apparatus (303) gets the response (317) from server, authenticates, extracts payload, 
               
               
                   
                 ACKS server (301). 
               
               
                 917. 
                 Apparatus (303) sends transaction result message data (315) such as status of 
               
               
                   
                 transaction, authorization code to kiosk (304) application. 
               
               
                 918. 
                 Kiosk (304) informs payer (324) of the results of the authorization such as approved 
               
               
                   
                 or declined. Kiosk (304) prints a receipt. 
               
               
                 919. 
                 Apparatus (303) returns to listener mode waiting for the next message from kiosk 
               
               
                   
                 (304) or server.(301) 
               
               
                   
               
            
           
         
       
     
     The above-mentioned steps are provided as exemplary. Steps can be eliminated, combined, or added without departing from the invention. Moreover, in certain embodiments, steps can be performed in a different order without departing from the invention. 
     Exemplary Method for “Card not Present” Transaction 
     With reference now to  FIG. 10 , an exemplary flowchart is provided, for an example sequence of a “card not present” transaction with an attended call center workstation in a system environment in accordance with the present invention. In the exemplary embodiment, the steps are performed as follows: 
     
       
         
           
               
               
             
               
                   
               
               
                 Step 
                 Task 
               
               
                   
               
             
            
               
                 1000. 
                 Payer (224) contacts call center to perform a payment. 
               
               
                 1001. 
                 Workstation operator (225) takes call and asks for payer (224) ID information. 
               
               
                 1002. 
                 Operator (225) enters payer data and retrieves amount due for services and/or 
               
               
                   
                 products. Operator (225) and payer (324) interact to determine which services and/or 
               
               
                   
                 products the payer (224) will pay for. 
               
               
                 1003. 
                 Operator (225) informs payer (224) of the total amount of the transaction, receives a 
               
               
                   
                 verbal confirmation and initiates the payment transaction on the workstation. 
               
               
                 1004. 
                 Payer (224) provides electronic payment data such as a credit card primary account 
               
               
                   
                 number, name on the card, card type, expiration date, and security code. 
               
               
                 1005. 
                 Workstation (204) application (may be an executable program or a browser page) 
               
               
                   
                 sends a “start payment request” (208) to apparatus (203). The request may include 
               
               
                   
                 amount, items and/or services identifiers, merchant ID, and other data needed to 
               
               
                   
                 process the transaction. 
               
               
                 1006. 
                 Apparatus (203) ACKs (215) the workstation (204) request (208) 
               
               
                 1007. 
                 Apparatus (203) application formats the first device (205, 206, 207) command and 
               
               
                   
                 sends the message (209, 211, 213) to the secure keypad device (205, 206, 207). 
               
               
                   
                 Additional commands may be used based on the transaction requirements and device 
               
               
                   
                 (205, 206, 207) configuration. 
               
               
                 1008. 
                 The device (205, 206, 207) enters encrypting key entry mode to capture payment data 
               
               
                   
                 such as credit card number, expiry date, and CVV. Other data may be requested for 
               
               
                   
                 address verification and other purposes. (Device (205, 206, 207) may be 
               
               
                   
                 preconfigured for the data entry sequence or data capture may be controlled by 
               
               
                   
                 apparatus.) 
               
               
                 1009. 
                 The operator (225) requests the payer&#39;s (224) payment card information and enters it 
               
               
                   
                 on the secure keypad (205, 206, 207). Data includes the payment amount, items 
               
               
                   
                 and/or services identifiers, merchant ID, payer (224) data, and other transaction data. 
               
               
                   
                 The message may include the ID of the device used for payer&#39;s (224) payment data 
               
               
                   
                 entry. 
               
               
                 1010. 
                 Operator (225) enters payer (224) data on the secure keypad device (205, 206, 207). 
               
               
                 1011. 
                 Device formats the data, encrypts it, and sends it to apparatus in one or more 
               
               
                   
                 messages. 
               
               
                 1012. 
                 Apparatus (203) receives the secure keypad messages (210, 212, 214) and builds a 
               
               
                   
                 server (201) transaction. Apparatus formats the header and trailer, adds 
               
               
                   
                 authentication data, and encrypts the data. 
               
               
                 1013. 
                 Apparatus (203) sends the transaction message (216) to server (201) and a status 
               
               
                   
                 message (215) to the workstation (204) application. Workstation (204) application 
               
               
                   
                 displays the status for the operator (225). 
               
               
                 1014. 
                 Server (201) receives the payment data message (216), authenticates it and extracts 
               
               
                   
                 data. 
               
               
                 1015. 
                 Server (201) updates the device and transaction databases (221) (Transaction 
               
               
                   
                 date/time, etc. No sensitive data retained) 
               
               
                 1016. 
                 Server (201) processes the payment transaction (e.g. an authorization)—sends the 
               
               
                   
                 authorization request (218) to the payment network (222). 
               
               
                 1017. 
                 Server (201) receives the authorization response (219) from payment network (222). 
               
               
                 1018. 
                 Server (201) builds the authorization results message (217) and sends it to apparatus 
               
               
                   
                 (203). 
               
               
                 1019. 
                 Apparatus (203) gets the response (219) from server (201), authenticates, extracts 
               
               
                   
                 payload, ACKS (216) server (201). 
               
               
                 1020. 
                 Apparatus (203) sends transaction result message (215) data such as status of 
               
               
                   
                 transaction, authorization code to kiosk (204) application. 
               
               
                 1021. 
                 Apparatus returns to listener mode waiting for the next message from kiosk or server. 
               
               
                   
               
            
           
         
       
     
     The above-mentioned steps are provided as exemplary. Steps can be eliminated, combined, or added without departing from the invention. Moreover, in certain embodiments, steps can be performed in a different order without departing from the invention. 
     With reference now to  FIG. 11 , an exemplary flowchart is provided, for an example sequence of a card present transaction communication sequence with a device in a system environment in accordance with the present invention, such as  FIG. 3 . In the exemplary embodiment, the steps are performed as follows: 
     
       
         
           
               
               
             
               
                   
               
               
                 Step 
                 Task 
               
               
                   
               
             
            
               
                 1101. 
                 Payment device (1405, 1406, 1407) displays a message that informs the payer (1424) 
               
               
                   
                 to insert, wave or swipe their payment card, press a button or otherwise indicate the 
               
               
                   
                 start of a transaction. 
               
               
                 1102. 
                 Payer (1424) starts the transaction by interacting with device (1405, 1406, 1407). 
               
               
                 1103. 
                 Device (1405, 1406, 1407) enters encrypting entry mode. Device (1405, 1406, 1407) 
               
               
                   
                 instructs the payer (1424) to perform the payment data capture event such as inserting 
               
               
                   
                 a credit card. 
               
               
                 1104. 
                 Payer (1424) provides payment card information and other data as needed. 
               
               
                 1105. 
                 Device (1405, 1406, 1407) captures and validates payer&#39;s (1424) payment data. 
               
               
                 1106. 
                 Device (1405, 1406, 1407) encrypts payer&#39;s (1424) captured data, formats a message 
               
               
                   
                 to apparatus (1403) and sends the message (1410, 1412, 1414) to apparatus. 
               
               
                 1107. 
                 Apparatus (1403) receives device (1405, 1406, 1407) message, parses the data, 
               
               
                   
                 validates the message and formats a message for server (1401). 
               
               
                 1108. 
                 Apparatus (1403) sends message (1416) to server (1401) and a status message (1409, 
               
               
                   
                 1411, 1413) to device (1405, 1406, 1407). The server (1401) message (1417) may 
               
               
                   
                 include the ID of the device (1405, 1406, 1407) used for capturing payer&#39;s (1424) 
               
               
                   
                 data entry or the current default port may be used. Device (1405, 1406, 1407) may 
               
               
                   
                 display the status for the payer (1424). 
               
               
                 1109. 
                 Server (1401) receives the payment data package, authenticates it and extracts the 
               
               
                   
                 payload. 
               
               
                 1110. 
                 Server (1401) updates the transaction and device databases (1421) (Transaction 
               
               
                   
                 date/time, etc. No sensitive data is retained.) 
               
               
                 1111. 
                 Server (1401) acquires the transaction payment amount based on the data sent from 
               
               
                   
                 apparatus (1403). 
               
               
                 1112. 
                 Server (1401) formats a response message (1417) including the transaction payment 
               
               
                   
                 amount and other data needed to complete the transaction and sends message (1417) 
               
               
                   
                 to apparatus (1403). 
               
               
                 1113. 
                 Apparatus (1403) receives server (1401) message (1417), parses the message, 
               
               
                   
                 validates the payload, formats a confirmation request message (1409, 1411, 1413) and 
               
               
                   
                 sends it to device (1405, 1406, 1407). 
               
               
                 1114. 
                 Device (1405, 1406, 1407) displays the confirmation message including amount of 
               
               
                   
                 the transaction. Payer interacts with device (1405, 1406, 1407) to accept the 
               
               
                   
                 transaction. 
               
               
                 1115. 
                 Device (1405, 1406, 1407) formats a response (1410, 1412, 1414) confirming payer 
               
               
                   
                 (1424) acceptance and sends it to apparatus (1403). 
               
               
                 1116. 
                 Apparatus (1403) receives the device (1405, 1406, 1407) confirmation message 
               
               
                   
                 (1410, 1412, 1414), formats a transaction message (1416) including apparatus (1403) 
               
               
                   
                 and device (1405, 1406, 1407) identification information and sends it to server 
               
               
                   
                 (1401). 
               
               
                 1117. 
                 Server (1401) processes the payment transaction (e.g. an authorization)—sends the 
               
               
                   
                 authorization request (1418) to the payment network (1422). 
               
               
                 1118. 
                 Server (1401) receives the authorization response (1419). 
               
               
                 1119. 
                 Server (1401) builds the authorization results message (1417) and sends it to 
               
               
                   
                 apparatus.(1403) 
               
               
                 1120. 
                 Apparatus (1403) receives the response (1417) from server (1401), authenticates, 
               
               
                   
                 extracts payload, and ACKS (1416) server (1401). 
               
               
                 1121. 
                 Apparatus (1403) sends transaction result message (1409, 1411, 1413) including data 
               
               
                   
                 such as status of transaction and authorization code to device (1405, 1406, 1407). 
               
               
                 1122. 
                 Device (1405, 1406, 1407) informs payer (1424) of the results of the authorization 
               
               
                   
                 such as approved or declined. 
               
               
                 1123. 
                 Apparatus (1403) returns to listener mode waiting for the next message (1410, 1412, 
               
               
                   
                 1414) from device (1405, 1406, 1407) or message (1417) server (1401). 
               
               
                   
               
            
           
         
       
     
     The above-mentioned steps are provided as exemplary. Steps can be eliminated, combined, or added without departing from the invention. Moreover, in certain embodiments, steps can be performed in a different order without departing from the invention. 
     Exemplary Method for No Workstation and Local Control Flow 
     With reference now to  FIG. 12 , an exemplary flowchart is provided, for an example sequence of a card present transaction communication sequence with a device in a system environment in accordance with the present invention, such as  FIG. 3 . In the exemplary embodiment, the steps are performed as follows: 
     
       
         
           
               
               
             
               
                   
               
               
                 Step 
                 Task 
               
               
                   
               
             
            
               
                 1201. 
                 Payment device displays a message that informs the Payer (1424) to insert, wave or 
               
               
                   
                 swipe their payment card, press a button or otherwise indicate the start of a 
               
               
                   
                 transaction. 
               
               
                 1202. 
                 Payer (1424) starts the transaction by interacting with the device (1405, 1406, 1407). 
               
               
                 1203. 
                 Device (1405, 1406, 1407) enters encrypting entry mode. Device (1405, 1406, 1407) 
               
               
                   
                 instructs the payer (1424) to perform the payment data capture event such as inserting 
               
               
                   
                 a credit card. 
               
               
                 1204. 
                 Payer (1424) provides payment card information and other data as needed. 
               
               
                 1205. 
                 Payer (1424) provides payment amount or device (1405, 1406, 1407) calculates 
               
               
                   
                 amount of the transaction. Amount calculation may be based on data such as location 
               
               
                   
                 and time of day or data captured by device (1405, 1406, 1407) such as scanning a bar 
               
               
                   
                 code. 
               
               
                 1206. 
                 Device (1405, 1406, 1407) formats a message to apparatus (1403) including data such 
               
               
                   
                 as amount, date and time stamp, location, and device (1405, 1406, 1407) identifying 
               
               
                   
                 data. 
               
               
                 1207. 
                 Device (1405, 1406, 1407) encrypts payer&#39;s (1424) captured data and other data and 
               
               
                   
                 sends message (1410, 1412, 1414) to apparatus (1403). 
               
               
                 1208. 
                 Apparatus (1403) receives device (1405, 1406, 1407) message (1410, 1412, 1414), 
               
               
                   
                 parses the data, validates the data and message and formats a message for server 
               
               
                   
                 (1401). 
               
               
                 1209. 
                 Apparatus (1403) sends the message (1416) to server (1401) and a status message 
               
               
                   
                 (1409, 1411, 1413) to device (1405, 1406, 1407). The server (1401) message may 
               
               
                   
                 include device (1405, 1406, 1407) identification data such as the serial number of 
               
               
                   
                 device (1405, 1406, 1407) used for capturing payer&#39;s (1424) data entry or the current 
               
               
                   
                 default port (508, 509, 510, 511, 512). Device (1405, 1406, 1407) may display a 
               
               
                   
                 status for the payer (1424). 
               
               
                 1210. 
                 Server (1401) receives the payment data package, authenticates it and extracts the 
               
               
                   
                 payload. 
               
               
                 1211. 
                 Server (1401) updates the transaction and device databases (1421) (Transaction 
               
               
                   
                 date/time, etc. No sensitive data is retained.) 
               
               
                 1212. 
                 Server (1401) processes the payment transaction (e.g. an authorization)—sends the 
               
               
                   
                 authorization request (1418) to the payment network (1422). 
               
               
                 1213. 
                 Server (1401) receives the authorization response (1419). 
               
               
                 1214. 
                 Server (1401) builds the authorization results message (1417) and sends it to 
               
               
                   
                 apparatus.(1403) 
               
               
                 1215. 
                 Apparatus (1403) receives the response (1417) from server (1401), authenticates, 
               
               
                   
                 extracts payload, and ACKS (1416) server (1401). 
               
               
                 1216. 
                 Apparatus (1403) sends transaction result message (1410, 1412, 1414) including data 
               
               
                   
                 such as status of transaction and authorization code to device (1405, 1406, 1407). 
               
               
                 1217. 
                 Device (1405, 1406, 1407) informs payer (1424) of the results of the authorization 
               
               
                   
                 such as approved or declined. 
               
               
                 1218. 
                 Apparatus (1403) returns to listener mode waiting for the next message (1410, 1412, 
               
               
                   
                 1414) from device (1405, 1406, 1407) or message (1417) server (1401). 
               
               
                   
               
            
           
         
       
     
     The above-mentioned steps are provided as exemplary. Steps can be eliminated, combined, or added without departing from the invention. Moreover, in certain embodiments, steps can be performed in a different order without departing from the invention. 
     Exemplary Method for No Workstation with Remote Server Control Flow 
     With reference now to  FIG. 13 , an exemplary flowchart is provided, for an example sequence of a card present transaction communication sequence with a device in a system environment in accordance with the present invention, such as  FIG. 3 . In the exemplary embodiment, the steps are performed as follows: 
     
       
         
           
               
               
             
               
                   
               
               
                 Step 
                 Task 
               
               
                   
               
             
            
               
                 1301. 
                 Device (1405, 1406, 1407) displays a message that informs the Payer to insert, wave 
               
               
                   
                 or swipe their payment card, press a button or otherwise indicate the start of a 
               
               
                   
                 transaction. 
               
               
                 1302. 
                 Payer (1424) starts the transaction by interacting with device (1405, 1406, 1407). 
               
               
                 1303. 
                 Device (1405, 1406, 1407) enters encrypting entry mode. Device (1405, 1406, 1407) 
               
               
                   
                 instructs the payer (1424) to perform the payment data capture event such as inserting 
               
               
                   
                 a credit card. 
               
               
                 1304. 
                 Payer (1424) provides identification information and other data as needed. 
               
               
                 1305. 
                 Device (1405, 1406, 1407) formats a message (1410, 1412, 1414) to apparatus (1403) 
               
               
                   
                 including data such as date and time stamp, location, payer (1424) identifying data, 
               
               
                   
                 and device (1405, 1406, 1407) identifying data. 
               
               
                 1306. 
                 Device (1405, 1406, 1407) encrypts payer&#39;s (1424) captured data and other data and 
               
               
                   
                 sends message (1410, 1412, 1414) to apparatus (1403). 
               
               
                 1307. 
                 Apparatus (1403) receives device (1405, 1406, 1407) message (1410, 1412, 1414), 
               
               
                   
                 parses the data, validates the message and formats a message for server (1401). 
               
               
                 1308. 
                 Apparatus (1403) sends the message (1416) to server (1401) and a status message 
               
               
                   
                 (1409, 1411, 1413) to device (1405, 1406, 1407). Server (1401) message may 
               
               
                   
                 include device (1405, 1406, 1407) identification data such as the serial number of 
               
               
                   
                 device (1405, 1406, 1407) used for capturing payer&#39;s (1424) data entry or the current 
               
               
                   
                 default port (508, 509, 510, 511, 512). Device (1405, 1406, 1407) may display a 
               
               
                   
                 status for the payer (1424). 
               
               
                 1309. 
                 Server (1401) receives the message (1416), authenticates it and extracts the payload. 
               
               
                 1310. 
                 Server (1401) updates the transaction and device databases (1421) (Transaction 
               
               
                   
                 date/time, etc. No sensitive data is retained.) 
               
               
                 1311. 
                 Server (1401) acquires payment amount based on the payer (1424) and device (1405, 
               
               
                   
                 1406, 1407) identification data. 
               
               
                 1312. 
                 Server (1401) formats an amount confirmation request message (1417) and sends 
               
               
                   
                 message to apparatus (1403). 
               
               
                 1313. 
                 Apparatus (1403) parses and authenticates server (1401) message (1417), formats a 
               
               
                   
                 message (1409, 1411, 1413) and sends message to device (1405, 1406, 1407). 
               
               
                 1314. 
                 Device (1405, 1406, 1407) displays a message requesting payer (1424) confirmation. 
               
               
                   
                 Payer (1424) confirms amount and provides payment card data. 
               
               
                 1315. 
                 Device (1405, 1406, 1407) formats, encrypts a message (1410, 1412, 1414) and sends 
               
               
                   
                 it to apparatus (1403) including payment card data, device (1405, 1406, 1407) 
               
               
                   
                 identifying data, date and time stamps and other data as needed. 
               
               
                 1316. 
                 Apparatus (1403) receives device (1405, 1406, 1407) confirmation and payment data 
               
               
                   
                 message (1410, 1412, 1414) formats a server (1401) message (1416) and sends the 
               
               
                   
                 message to server (1401). 
               
               
                 1317. 
                 Server (1401) processes the payment transaction (e.g. an authorization)—sends the 
               
               
                   
                 authorization request (1418) to the payment network (1422). 
               
               
                 1318. 
                 Server (1401) receives the authorization response (1419). 
               
               
                 1319. 
                 Server (1401) builds the authorization results message (1417) and sends it to 
               
               
                   
                 apparatus.(1403) 
               
               
                 1320. 
                 Apparatus (1403) receives the response (1417) from server (1401), authenticates, 
               
               
                   
                 extracts payload, and ACKS (1416) server (1401). 
               
               
                 1321. 
                 Apparatus (1403) sends transaction result message (1409, 1411, 1413) including data 
               
               
                   
                 such as status of transaction and authorization code to device (1405, 1406, 1407). 
               
               
                 1322. 
                 Device (1405, 1406, 1407) informs payer (1424) of the results of the authorization 
               
               
                   
                 such as approved or declined. 
               
               
                 1323. 
                 Apparatus (1403) returns to listener mode waiting for the next message (1410, 1412, 
               
               
                   
                 1414) from device (1405, 1406, 1407) or message (1417) server (1401). 
               
               
                   
               
            
           
         
       
     
     The above-mentioned steps are provided as exemplary. Steps can be eliminated, combined, or added without departing from the invention. Moreover, in certain embodiments, steps can be performed in a different order without departing from the invention. 
     With reference now to  FIG. 14 , there is shown another exemplary system environment for electronic payment transactions in accordance with the present invention. The system includes a DCM apparatus  1403 , in accordance with the present invention, is installed and communicatively connected to peripheral devices  1405 ,  1406 ,  1407 , in order to isolate the local environment from transaction data, device operation and device management. Apparatus  1403  further isolates from transaction data the local network and its workstations. 
     The apparatus  1403  communicates through an Internet connection with server  1401  and through USB or RS232 connections communicates with devices  1405 ,  1406  and  1407 . In the example, the Internet connection  1402  can be wired or wireless Ethernet or other connection type or protocol. Communication between apparatus  1403  and server  1401  can be via a private network or other network such as cellular service. Devices  1405 ,  1406 ,  1407  may be a such as multi-function POS device, PIN pad, card reader, signature capture device, printer, check scanner, printer or other peripheral used in a transaction processing system. Apparatus  1403  is configured to execute software comprising an operating system, a plurality of applications, communication port management software, and device drivers. 
     Any of devices  1405 ,  1406 ,  1407  sends a request  1410 ,  1412 ,  1414  to apparatus  1403  to initiate a transaction. Alternatively, server  1401  sends an initiation message  1417  to apparatus  1403 . The request includes data necessary for software executing in apparatus  1403  to initiate the transaction includes such as merchant ID, date and time. On receipt of a valid request, apparatus  1403  formats messages  1409 ,  1411 , or  1413  to be sent to a peripheral device  1405 ,  1406 , or  1407 . The target device  1405 ,  1406 ,  1407  receives message  1409 ,  1411 ,  1413  and performs interactions with a payer ( 1424 ) to capture additional data. The additional data comprises data such as payment credit card data from payer ( 1424 ), personal identification number (PIN), electronic signature, transaction amount, and responses to marketing queries. Upon completion of the capture of the additional data, the device formats a message  1410 ,  1412 ,  1414  and sends message to apparatus  1403 . The message or data therein may be encrypted. Data specific to the device such as device ID, date, time, and other data needed to manage the device or process the transaction may be included in the message. 
     On receipt of the device message  1410 ,  1412 ,  1414 , apparatus  1403  parses the message and validates the data, and determines if the transaction can continue. At this time, if there is any reason why the transaction cannot continue, apparatus  1403  may respond to device  1405 ,  1406 ,  1407  with an error condition. Given the transaction can continue, apparatus  1403  formats a server message  1416 . Said message comprises payment data, authentication data, apparatus ID, apparatus firmware revision, and other data necessary for the transaction. The message  1416  or portions thereof may be encrypted by apparatus  1403  including but not limited to, individual data elements, multiple data elements, and the entire message. Apparatus  1403  sends the message  1416  to server  1401 . A protocol such as PCT, SSL or TLS may be used for message security. Upon receipt, server  1401  parses the message  1416 , determines source and type of message, and processes the message to facilitate completion of the transaction. Server  1401  may decrypt the message or portions thereof. Processing may include authentication using any of data from apparatus  1403 , any of devices  1405 ,  1406 ,  1407 , and payer  1424  provided data used in the transaction. 
     Server  1401  may perform local processing such as querying and/or updating  1420  a database  1421 , verifying identifying data from any of apparatus  1403  and/or devices  1405 ,  1406 ,  1407 , authorization, fraud checking, and other related actions. If server  1401  determines there is any reason to prevent the transaction from being further processed, server  1401  may respond to apparatus  1403  with an error condition message. Additionally server  1401  may forward all or a portion of the message  1418  to one or more entities such as a payment processor  1423  or other third parties via network  1422 . Processor  1423  receives message  1418 , and takes further action based on the contents of the message  1418 . Said actions will include such as verifying the message  1418  data integrity, verifying sender identity, verifying merchant identity data, executing payment authorization, fraud checking, and database updates. Upon completion of processing the message  1418 , Processor  1423  responds with a result message  1419 . 
     Server  1401  receives message  1419 , and processes the message. Server  1401  may decrypt all or portions of message  1419  prior to processing said message. Server  1401  updates database  1421  based on the contents of message  1419 . Server  1401  formats a response  1417  to apparatus&#39;s  1403  message  1416 . The message  1417  and portions thereof may be encrypted by server  1401  including but not limited to, individual data elements, multiple data elements, and the entire message. Server  1401  may add data to the message  1419  including but not limited to the transaction processing result, configuration data  519  for any of apparatus  1403  or devices  1405 ,  1406 ,  1407 , and other data needed to complete the transaction. Server  1401  sends the response message  1417  to apparatus  1403 . 
     Upon receipt of message  1417 , apparatus  1403  processes the message and determines the transaction processing result. Apparatus formats a completion message  1409 ,  1411 ,  123  and transmits the one or more messages to devices  1405 ,  1406 ,  1407 . Upon completion of the transaction, apparatus  1403  resumes “listening mode” and waits for a message from any of server  1401  or devices  1405 ,  1406 ,  1407 . 
     The present invention has been described above in terms of presently preferred embodiments so that an understanding of the present invention can be conveyed. However, there are other embodiments not specifically described herein for which the present invention is applicable. Therefore, the present invention should not to be seen as limited to the forms shown, which is to be considered illustrative rather than restrictive.