Technical Information

Detailed information is contained in the documentation. Using oPAYc Drivers, Inline has developed a new way for Merchants to make secure payment transactions. The Inline Open Payment Connectivity (oPAYc) Model is based on ODBC (open database connectivity) technology. The oPAYc drivers basically work the same way as a driver communicating with any other datasource, only they communicate directly with a payment server instead of a database server. This solution is cross platform and runs on Windows, Solaris, Linux, BSDi, FreeBSD, and SCO

DSNs (data source names) are associated with a driver and a specific instance of operation. For example a host, port, and merchant id bind a driver to a particular instance of use. The actual setting required in the DSN for a given driver vary, and details of them are contained in the corresponding .config.ini file to the driver. This file contains meta information which although human readable, is also used by an ihtx extension tag in iHTML to provide dynamic configuration forms for any driver using this system. Example code for other languages is provided in the documentation.

Data is communicated to and from the drivers using standard sql syntax, just as if it were a database. The pseudo-table that the drivers use for clearing financial transactions is called "transactions". This is the only table supported by the drivers.

A financial transaction is accomplished by a select statement of the form:

select * from transactions where ...

Various clauses may appear to the right of the where. They are detailed in the documentation. While a given driver may not require all of the clauses, they all should be supplied to any driver used, since this will facilitate switching drivers easily at any point.

The Gateways De-mystified

Faced with the problem of dealing with a very large number of transaction gateways for our own e-commerce applications, Inline has classified all systems we deal with into three basic families according to how the e-commerce application interacts with the gateway. These families cover all the gateways we have encountered so far. They are "Redirect", "TCP/IP and SSL", and "C-API". Inline has also seen the need for various types of "offline" transaction processing and has created a number of our own drivers that do not actually process the transactions in real time, but instead simply record the requested transactions for later processing. They can also be used in conjunction with a real time driver so that after a transaction is approved the offline driver is simply used to keep a record of it.


This type of gateway is normally the simplest for the low-end merchant to integrate, however, it suffers from a number of issues that the oPAYc drivers address. The way this system works essentially, is the e-commerce app is assumed to be web based, and generates some variables in a form which is passed to the user. One of the variables is normally the amount, and another is a unique id for the transaction. The browser is redirected to the gateway website which is using SSL for security. The user then enters in another form their credit card details, this is submitted to the gateway webserver. After processing the request, the browser is again redirected back to a url on the Merchant site which is used to determine the success or failure of the transaction based on either the url used or the content of response.

There are several issues with this type of system which in the normal manner of use make it undesirable for certain applications.

First, there is the stigma of the redirect to another site to accept payments. This is purely subjective, but can be an issue. To address this with oPAYc, the customer interacts with the e-commerce application directly only, and the e-commerce application handles all interaction with the gateway via the driver, and this process is hidden from the user.

Second, there is normally no facility for repeated transactions such as monthly billing to happen through this sort of system. This is because the card holder has to actually interact with it each time a transaction goes through. Since with oPAYc, the e-commerce application communicates with the gateway through the driver, it has access to all the customer information such as credit card number, expiry and so on, and may store these for later use to process repeated transactions for applications such as monthly billing or quick order without the customer re-entering the information.

Another issue, is that since the transaction actually "flows" from the webserver to the browser to the gateway server, it is subject to tampering (fraud). The oPAYc drivers address this security risk but making the flow of the transaction - browser to webserver to gateway only, so the user has no control over the response the webserver gets from the gateway. Note: in an oPAYc system this may be only Application Server to Gateway, if the e-commerce application does not include a web based front end.

This type of gateway is also normally only usable if the e-commerce application has a user interface with a web browser. People generally associate the two, but it is not necessarily the case. The oPAYc drivers for these systems work equally well regardless of if the process driving them is web based or not.


This category of payment system gateway may or may not be encrypted using SSL. If the gateway software is running on the same machine as the webserver, or within a secured LAN segment, the encryption does not increase security. In any case though, this type of system uses the TCP/IP networking protocol to transfer data between the driver and the gateway. This may use the http protocol, or it may define its own proprietary data format for a request and response.


This category of system generally also uses tcp/ip sockets, but may use other methods such as file drop or modem SLIP dialup for communications. The encryption involved if applicable is usually not SSL, but rather triple DES or something similar, sometimes with MD5 Hashing as well. The gateway vendor provides the low level communications code written in C, and the driver simply makes API calls to the vendor's code to execute various actions.


This type of driver does not actually interface with a real time payment system gateway. The drivers available in this category include ODBC, email, and logfile. Each of the drivers simply records the information in one of the three places they communicate with and returns, without indicating the transaction was actually processed.
Copyright © 1998-2008 Inline Internet Systems, Inc.