Credit card processing.. more info

Richard Miller wow at
Sat Jan 22 12:02:33 EST 2005

We've received a bit more information on this issue of processing a 
credit card transaction from within a Rev app, and I'm hoping someone 
here can help interpret it. Please shed any light you can. This 
response comes from the folks at e-Onlinedata / Thanks. 


Take a look at our documentation page 
(  I just want to make 
sure you are looking at the Card Present (CP) Implementation Guide PDF 
and not the AIM guide (which is ecommerce).  It tells you in that 
document that the URL you POST to 
is  The data 
does not need to be encrypted because you are emulating the HTML form 
POST using SSL.  SSL takes care of the encryption and decryption.  You 
will be using our digital certificate, so you will not need one for 
each kiosk.
The request string looks just like what you would see for a GET method 
on an HTML form.  Here is some sample code in VBScript.  It won't apply 
to you but you will get the idea of how to put it together.  You will 
want to use a device type of 5 and a market type of 2.
                ' build the request string
                vPostData = _
                    "x_cpversion=1.0" & _
                    "&x_login=" & Server.URLEncode( x_login ) & _
                    "&x_tran_key=" & Server.URLEncode( x_tran_key ) & _
                    "&x_market_type=" & x_market_type & _
                    "&x_device_type=" & x_device_type & _
                    "&x_amount=" & x_amount & _
                    "&x_description=" & Server.URLEncode( merchant_name 
) & _
                    "&x_response_format=1" & _
                    "&x_delim_char=" & x_delim_char & _
                    "&x_test_request=" & x_test_request
                Select Case validation_method
                    Case 2 vPostData = vPostData & "&x_track2=" & 
Server.URLEncode( x_track2 )
                    Case 3 vPostData = vPostData & "&x_card_num=" & 
x_card_num & "&x_exp_date=" & x_exp_date
                    Case Else vPostData = vPostData & "&x_track1=" & 
Server.URLEncode( x_track1 )
                End Select

                ' Send data via HTTPS POST to
                set objHttp = 
       "POST", auth_net_url, False
                objHttp.SetRequestHeader "Content-Type", 
                objHttp.send (vPostData)
                If( objHttp.Status = "200" ) Then
                    ' we communicated with web server successfully so 
now process the response
                    vResponseText = objHttp.responseText
                    ' Tokenize response . Separator is x_delim_char
                    vFieldArray = Split( vResponseText, x_delim_char, 
-1, 1 )
                    vNumFields = Ubound(vFieldArray)
Let me know if I you get stuck again.

Keith Bailey  |  Manager, Integration Services
Authorize.Net  |  a Service of Lightbridge
915 South 500 East  |  Suite 200  |  American Fork  |  UT  |   84003
Telephone  801.492.6483  |  Fax  801.492.6500  | 

kbailey at  |  |
-----Original Message-----
From: richard at [mailto:richard at]
Sent: Friday, January 21, 2005 10:22 AM
To: Keith Bailey
Subject: Re: Our conversation; re: Keith


Thanks for getting back to me on this. It's been extremely frustrating 
trying to get an answer to this question. Any help you can offer is 
greatly appreciated.

We are running on Mac OS X. We have no problem emulating the HTML form 
POST. The programming environment we are working in allows for that. 
The problem is in opening the secure connection to AIM. Perhaps you can 
walk me through this. Here's the situation.

1. We have a laptop somewhere in the field.

2. The only program available on this machine is a custom application 
(there's no browser available).

3. We collect the card data and organize that data into an appropriate 

4. What happens next? Where is that data sent? What's the address? How 
do we create a secure connection? How do we encrypt that data? This is 
where we're stuck.


On Jan 21, 2005, at 12:11 PM, Keith Bailey wrote:

Hopefully I can help shed a little light on using AIM.  I couldn't tell 
from your conversation if you are running on any specific OS or if your 
kiosks are simply self-contained with custom applications running 
directly on the hardware.  Since the Authorize.Net gateway is accessed 
through the Internet, a certain platform or programming language is not 
needed, simply the ability to emulate an HTML form POST using SSL.  
Most languages have libraries or objects that make this an easy task, 
such as WinHTTP or XMLHTTP for Windows, LWP for Perl, curl for PHP, 
etc.  The process is to build the request string with the field names 
and values, POST it and wait for the response string to be returned 
within 3-10 seconds.  You can select whether the response string is 
returned as a delimited array string or XML.
Let me know if you have any other questions.

Keith Bailey  |  Manager, Integration Services
Authorize.Net  |  a Service of Lightbridge
915 South 500 East  |  Suite 200  |  American Fork  |  UT  |   84003
Telephone  801.492.6483  |  Fax  801.492.6500  | 

kbailey at  |  |
  -----Original Message-----
From: John Waldron [mailto:jwaldron at]
Sent: Thursday, January 20, 2005 7:19 PM
To: Keith Bailey
Subject: FW: Our conversation; re: Keith
Importance: High

Keith....can you please help Richard with his questions on Integration 
for his Kiosk......please let me know if I need to fill in any blanks.

John Waldron
-----Original Message-----
From: Richard Miller [mailto:richard at]
Sent: Thursday, January 20, 2005 9:16 PM
To: jw at
Subject: Our conversation; re: Keith


As per our discussion, here is what we are looking at needing a 
solution for.

We're working with a portable kiosk. It has a wireless connection. Our 
customers are restricted to our custom application. There is no mouse 
or keyboard available... touch screen only. We have a card reader 
attached to the unit. How do we get the credit card information from 
our unit out to e-onlinedata, processed, and then back to our unit?

We've reviewed the CP Guide. No problem collecting the card information 
and configuring the data so that the appropriate information is sent to 
you. No problem deciphering the data once it comes back to our unit.

Where we are stuck is with this part of the CP Guide directions 
(identified by the asterisks below):


How Does AIM Work?

When using AIM, transactions flow in the following way:

******** 1. The Merchant’s server initiates a secure connection to the 
payment gateway and then initiates an HTTPS POST of the transaction 
data to the gateway server ********

2. The payment gateway receives and processes the transaction data
3. The payment gateway then generates and submits the transaction 
response to the Merchant’s server
4. The Merchant’s server receives and processes the response
5. Finally, the Merchant prints a receipt and obtains the cardholder’s 
signature to complete the transaction

What is Required to Implement AIM?

Merchants must be able to perform the following functions in order to 
submit transactions to the gateway using AIM:

******** 1. Establish a secure socket connection  ********
******** 2. Provide both server and client side encryption ********

3. Develop scripts on a Web server for the integration to the gateway 
(e.g., for submitting transaction data and receiving system responses)

AIM Implementation

To implement AIM, a developer would design a script that can do the 

1. Securely obtain all of the information needed to process a 

******** 2. Initiate a secure HTTPS form POST from the merchant’s 
server to  ********

3. Receive the response from the gateway and process the response to 
display the appropriate result to the end user

Note: For reasons of security, use only port 443 for AIM information 


Our application has been developed with a programming environment 
called Revolution ( It's like a high level version of 
C++. We're guessing we need to use the built-in commands OPEN SECURE 
SOCKET and ENCRYPT. Please read through this and let me know if this is 
the correct way to go and if you expect it will work.

Richard Miller
Imprinter Technologies


OPEN SOCKET COMMAND (SSL & Encryption library)

Platform support:
Introduced in version 1.0 (Changed in version 2.5)

Establishes a TCP communications socket between your system and another 

open [datagram] socket [to] host[:port[|ID]] [with message 
open secure socket [to] host[:port[|ID]] [with message callbackMessage] 
[with|without verification] [using certificate certificate and key key]

open socket to ""
open socket to "|sendFiles"
open socket to (field "Outgoing") with message "mailConnectionUp"
open secure socket to "" with message "wasConnected" 
with verification

Use the open socket command to open a connection to another system on 
the Internet (or another IP network) to get and send data.

The host is the IP address or domain name of the host you want to 
connect to.

The port is the port number you want to connect to. If you don't 
specify a port, port 80 is used. (On most systems, port 80 is used for 
HTTP connections.)

The ID is an optional connection name for the socket, and can be any 
string. Specify an ID if you want to create more than one socket to the 
same host and port number, so that you can distinguish between them.

The callbackMessage is the name of a message to be sent when the 
connection is made.

When a connection is made, the open socket command creates a new socket 
that can be used to communicate with the other system. The handler 
continues executing while the connection is being established. If you 
use the write to socket command while the connection is opening, the 
data is buffered and is sent to the host as soon as the connection is 

Use the open datagram socket form if you want to send a connectionless 
UDP datagram instead of opening a socket.

If you specify a callbackMessage, the message is sent to the object 
whose script contains the open socket command, as soon as the 
connection is made. The first parameter pf this message is the host and 
port number of the socket. Use a callbackMessage to trigger actions 
(such as reading from the socket) that must wait until the connection 
has been established. (To pause the handler that contains the open 
socket command until the callbackMessage is received, use the wait for 
messages form of the wait command.)

UDP/datagram sockets are not supported by SSL. When connecting to a 
remote peer, the client verifies the servers certificate during the 
handshake process and verifies it against a list of certificates. You 
can specify a list of root CA to verify against using the 
sslcertificates property (see sslurlloader sample). The sslcertficates 
property takes a return delimited list of files or folders. In addition 
you can place system wide certfificates in 

The most common CAs such as verisign can be found in the file root.pem. 
If 'without verification' is specified then server credentials are not 
authenticated, and any connection is accepted. Some servers require 
that the client submit a certificate as well, this will be supported in 
the next alpha.

If the socket fails to open due to an error, a socketError message is 
sent to the object that attempted to open the socket. (If the error is 
due to a problem finding the specified host, the error message is 
returned in the result, and no socketError message is sent.)

Note: When the accept command creates a socket, it assigns a number as 
the connection name. If you are using both the open socket command and 
the accept command to connect to the same port on the same host, make 
sure to use a non-numeric connection name that won't conflict with the 
numbers assigned by the accept command. This ensures that you can 
always refer to two different sockets by distinct socket identifiers.


ENCRYPT COMMAND (SSL & Encryption library)

Platform support:
Introduced in version 2.5
encrypt source using cypher with [password|key] passorkey[and salt 
saltvalue] [and IV IVvalue] [at bit ]

  See also: decrypt command, cipherNames function

Encrypt and decrypt accept the source data that will be 
encrypted/decrypted. cipher is the name of the cipher obtained using 
the ciphernames function. passorkey specifies the password of key that 
will be use for encryption/decryption. If you specify key then the key 
needs to be the same size as the current cipher key length. If you 
specify password or don't specify a key mode, then the password will be 
hashed with MD5, and combined with a salt value (a random string which 
is designed to deter hackers from using dictionary attacks with 
frequent hashed passwords) and truncated to the cipher key length.

The syntax allows for passing an optional salt value, and optional IV 
value. This will be supported in the next alpha. Currently the salt is 
a fixed value of 'salu' which is combined with the password hash and 
used to extract the key. If the user does not specify a salt is the 
next alpha then a random salt with be generated, and appended to the 
ecrypted data, which will be read and used when decrypted.

bit specifies the key length in bits (ie. 64, 128, 256) Some ciphers 
have fixed key lengths and attempting to set the key length will result 
in an arrow.

On failure encrypt/decrypt set the result to the appropriate ssl error 
message. On success the variable it will contain the 
encrypted/decrypted data.

To use OpenSSL functionality with Rev, make sure that the openssl 
shared library is installed, and in a place where Rev can find it. It 
is pre-installed with OSX. You can download and build OpenSSL at and sitribute with your apps. This alpha includes a 
prebuilt openssl dll which is required to use OpenSSL for windows 
(libeay32.dll) which needs to be in the application, current, or system 
directory. If Revolution cannot load SSL, it will return the error in 
the result "ssl library not found".

More information about the Use-livecode mailing list