Credit card processing.. more info

wow at wow at
Sat Jan 22 13:42:29 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. Richard


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
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 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

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 transaction

******** 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 callbackMessage]
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

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

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

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 made.

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 System/Library/OpenSSL/certs.

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

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

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

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".

mail2web - Check your email from the web at .

More information about the Use-livecode mailing list