Security Information

Surprisingly many payment processing systems are not fully secure. The oPAYc API system adds additional security where required to give those using the drivers the confidence needed when making online payments.

Since handling of sensitive information is involved here with oPAYc, many people have questions about how security is handled. This section will discuss all the various areas of the payment acceptance process, and how security is handled within them, and what the application programmer or system integrator needs to do to ensure the sensitive information remains secured.

First, there are configuration files, or application files for oPAYc which contain such information as the Merchant's account number and login credentials for the Payment Gateway. Although this information is not really useful to an outsider for purchase fraud, it can be used to examine transactions and void them, or inquire as to details of the merchant's account contents. This being the case, appropriate operating system permissions should be applied to the files to ensure they are not readable or writeable by users other than the one the e-Commerce Application runs as. The files should also be kept out of any directory trees accessible by remote file services such as the webserver, ftp server, drive mapping, etc.

Next there is the point where the credit card information is actually entered by the cardholder. If using a web based interface this page should be running on a webserver with ssl and a certificate enabled. This will ensure the data is encrypted, and also that the user trusts that the merchant is who they claim to be. If for example the e-Commerce app is a POS system running on a LAN, SSL is not such a big concern since the data is only travelling on a private network. If the data travels through any public portion of the network, then it should be encrypted in some manner. Possibilities are webserver using https, a firewall tunnel with encryption of some sort, various VPN solutions with an encryption layer, etc.

Once the sensitive data gets to the e-Commerce Application itself, there is somewhat of a choice, and every application has different needs. The most secure implementation from the cardholder point of view is if the information is used for the single transaction in question and then totally discarded by the application. However, Merchants may wish to store this data for their records, or they may require the data to be kept on file to use to process subsequent recurring transactions, or to avoid the customer having to re-enter the data. If the data persists on the application server, it must be secured as well. Files containing it should have restricted operating system permissions to disallow general users from seeing it. The same applies if it is in a database rather than a flat file. If the database is remote rather than local, the network between the two should either be private, or have some security layer running on it. Some databases support storing fields encrypted as well. The same data is going to appear on backups, so they need to be kept in areas with only authorized access as well.

Security between the e-Commerce Application and the Payment Gateway is normally handled in one of the following ways - private network, VPN, http with SSL layer, or TCP/IP with proprietary encryption. Generally private networks are used exclusively between the gateway and the issuing bank networks.
Copyright © 1998-2008 Inline Internet Systems, Inc.