Script-Based Credit Card Interfaces

To meet the demand for greater, more flexible access to real-time electronic transaction processing, transaction processing providers are lowering the barriers of entry, and opening the interfaces to their systems, allowing developers an opportunity to create custom interfaces for electronic commerce systems. In this article we show how easy it can be to connect your website to these systems and add real-time credit card processing to your programming arsenal.

Conducting real-time electronic commerce over the internet is clearly a requirement for any serious internet store, but these days it seems that smaller and smaller ventures seem to have a desire to tap into this new world of potential revenue. One option for these small businesses is to use one of many pre-packaged internet storefront products available from a variety of commerce providers, software developers, and consultants. However, these solutions typically offer limited customization and may have hefty setup and transaction fees. If you’re like me, and you need a tightly visually integrated solution, and you’d rather build than buy, then these solutions aren’t for you.

To meet this demand for greater, more flexible access to real-time electronic transaction processing, transaction processing providers are lowering the barriers of entry, and opening the interfaces to their systems, allowing developers an opportunity to create custom interfaces for electronic commerce systems. Providers, such as CyberCash and, will typically offer a number of different methods of interacting with their authorization systems, putting a remarkable amount of power and flexibility in the hands the savvy developer.

In this article, I will show how easy it can be to connect your website to these systems and add real-time credit card processing to your programming arsenal.

Before going into the specifics of picking a provider, providing appropriate security, and exchanging information from the service provider, we should first understand what steps are being taken in a typical electronic commerce transaction, and how those steps occur.

1. You establish secure connection with the user
2. You collect transaction information from the user (cc info, as well as name / address, etc.)
3. You send the user’s information to the commerce provider
4. Commerce provider sends information to credit card processing network for verification
5. Commerce provider receives authorization (or denial) information from network
6. Commerce provider sends result of transaction back to your site
7. You display the result of the transaction for the user

Please note that due to space concerns, this article will not cover the construction of internet shopping carts or the creation of commerce sites from scratch. I assume that you have the ability to create a transaction and are ready to submit it for processing. Also, though there are several providers who provider transaction authorization services, this article will discuss how to build a request / response interface with the system. Finally, the few snippets of sample code in this article are done in PHP.

{mospagebreak title=Pick a Provider} The first thing that you’ll have to do before starting work on your transaction system is to select the provider who will handle your transactions. If your development project is for someone other than yourself, the client may already have made this decision for you. Otherwise, you’ll have the opportunity to choose for yourself. Two of the most popular providers for this service are CyberCash and

CyberCash ( was one of the pioneers of the on-line payment authorization industry and is currently the leader in this field with over 25,000 merchants using their automated processing services, according to their website. They offer a wide variety of service options and interfaces, including the HTML form request / response interface that we will demonstrate below. For more detailed information about their product offerings and systems, please see their website., founded in 1996, is quickly building a reputation as a leading provider of internet transaction services. Like CyberCash, they offer a variety of options for connection with their verification system, and also provide some excellent tools for integration testing. They furnish comprehensive documentation for their systems, and a special testing interface so that you don’t even need to establish an account to build and test your system.

Though both services are equally viable solutions for your transaction processing needs, the bulk of this article will discuss how to build an HTML request / response interface with the system.

{mospagebreak title=A Word About Security} Since you’re going to be passing your customer’s sensitive credit card information through the site, and they would probably prefer that this information be protected from falling into the wrong hands, you should give them a measure of protection. Providing protection means providing an SSL (Secure Sockets Layer) connection to your site. In some cases, you can use your ISP’s certificate, but you’ll most likely need to purchase one from an authorized certificate provider such as VeriSign or Thawte Consulting. The SSL connection encrypts the form data that is passed from page to page (or script to script) within your commerce application, keeping the information from being easily read by prying eyes (or packet sniffers).

For more information about SSL connections, security certificates, and creating a secure environment for your transactions, check out or

{mospagebreak title=Building the Form, Making a Request} As previously discussed, provides several options for connecting to their system and processing the result. For the purposes of this demonstration, we’re going to use the request / response or “Relay Response” method of interaction. In the “Relay Response” transaction, information is sent through an HTML form from your site to the transaction server In your request, you specify the address to which you would like to have the response sent. After processing your request, the server responds with the result of the transaction to the URL you specify. In your response handling script, you process the variables and provide the user with feedback about the result of the transaction.

The minimum requirements for a transaction, according to the documentation, include the following pieces of information:

Information field name Account Name x_Login Credit Card Number x_Card_Num Credit Card Expiration x_Exp_Date Transaction Amount x_Amount Results Handling Method x_ADC_Relay_Response Results Handling Address x_ADC_URL Field Definitions Version x_Version

The login field is required to tell the system whose account to credit for the transaction, if successful. The card number and expiration date are required for card validation. Note that the card type (such as Visa, MasterCard, etc.) is not required, as this information can be gleaned by the processing system from the card number. Obviously, the amount of the transaction is indispensable.

The final three fields describe how the transaction is to take place. In this example, we will be using relay response, so we will set the x_ADC_Relay_Response field to a value of TRUE. In “direct response” transactions, you would set this value to FALSE, or simply not include the field at all. x_ADC_URL works in conjunction with the x_ADC_Relay_Response, and is only used in relay response transactions. This field tells the transaction server where to post the results of the transaction, and must include the full URL for your script that will process the result of the transaction. The final field, x_Version, tells the server that you’re using their version 3.0 for the purpose of defining the transaction, allowing for backward compatibility as their systems are upgraded.

So, our minimal sample form is going to look something like this:

<FORM method=”post” action=””>
<INPUT TYPE=”text” NAME=”x_Login” VALUE=”testing”>
<INPUT TYPE=”text” NAME=”x_Card_Num” VALUE=”4222222222222″>
<INPUT TYPE=”text” NAME=”x_Exp_Date” VALUE=”12-01″>
<INPUT TYPE=”text” NAME=”x_Amount” VALUE=”1.00″>
<INPUT TYPE=”hidden” NAME=”x_ADC_Relay_Response” VALUE=”TRUE”>
<INPUT TYPE=”hidden” NAME=”x_Version” VALUE=”3.0″>
<INPUT TYPE=”submit”>

Obviously, in a real transaction system, your amount values are already going to have been decided by this point, and fed by variables generated by a shopping cart or other system. The credit card information will have been collected from the user to fill in those fields. This simply shows what a transaction from might look like after being generated by PHP, or whatever scripting language you choose to use.

It is also worth noting customer address information, which is often used for further verification of a credit card transaction, is not required for the transaction to be completed, but it is strongly recommended. In addition to authorization of the card numbers and expiration date, also providers an Address Verification System (AVS) which will return additional response codes for the transaction based on the matching of address information with a credit card account. The address verification system settings are managed in the account control panel, and are not configured on a transaction-by-transaction basis.

For a full list of fields that can be passed and processed by the system, see your transaction server’s documentation. One particularly attractive feature of the system is that it will pass through any variables that are not specified in their field definitions. This is particularly useful if you write your web applications into a single “phased” scripts as opposed to a collection of scripts with specific functionality. The pass-through feature allows you to pass state information through the transaction server and pick it up on the other side of the transaction.

{mospagebreak title=Handling the Response} After submitting the transaction to your commerce provider, you should extend to your customers the courtesy of telling them what happened with their transaction. Not only is this reassuring, but it gives them the opportunity to re-submit the transaction with corrected information if the first transaction failed due to a mis-typed card number or expiration date.

A good transaction server will give you plenty of information to pass on to your users about what happened when their credit card was sent for authorization. not only provides information about the success or failure of the transaction, but very specific information about why a transaction failed, both in a numeric code and text description. If you’re using the address verification system (AVS) as well, additional response codes will be returned with the result of the transaction to show the result of the AVS checks. In addition to the result of the transaction, the transaction server also returns any and all fields that were sent to it, allowing you to do any additional processing of this information, if necessary.

The fields that show the result of the transaction are as follows:

Information field name
Overall Transaction Result Code x_response_code
Specific Result Reason Code x_response_reason_code
Specific Result Reason Text x_response_reason_text
Address Verification Results    x_avs_code
Authorization Code x_auth_code

The first response code provides only very basic information about the transaction, having one of three values: approved, declined, or error. An approved transaction needs little explanation, but the difference between declined transactions and error transactions may not be as clear. Declined transactions occur when a valid card number and expiration date are present, but there are insufficient funds available on the card to complete the transaction. An error transaction, on the other hand, typically indicates incorrect card information, or some other problem with verification of a card.

The next two fields, x_response_reason_code and x_response_reason_text directly related. There are 35 possible responses for this field, but most of them are for more advanced uses of the system. The most likely responses here are approval, denial, or the detailed explanation of an error code. AVS codes are similar to the response reason codes, except that no “reason text” is given for this field — the results must be interpreted and explained by a handling script.

Thus, the core of a simplified result script (in PHP) might look something like this:

if ($x_response_code == “1”) { // success!!
echo “Congratulations, your transaction was successful!<BR>”;
echo “Your credit card number $x_card_num was charged $x_amount.<BR><BR>”;
echo “Thank you for using our online store, and please come again.<BR>”;

else { // decline or error
echo “I’m sorry, but there was a problem with this transaction.<BR>”;
echo “The transaction server response was:

If this were a typical application, you would save the result of the transaction to a database for the successful transaction, and give your user the opportunity to correct their errors in the event of a failure.

You may have noticed that I skipped one of the fields in the transaction result, and I did so on purpose. To explain the authorization code, I will need to digress for a moment. Authorization codes would not be used in typical eCommerce transaction, but would be used in a scenario where you wanted to authorize a card for a certain amount of money without actually completing the transaction, so the authorization system responds with an authorization code for the transaction. At some future time, you will return with that authorization code and specify an amount to be “captured” from the card. Again, this type of transaction is uncommon for eCommerce, but very common for hotels, gasoline pumps, and restuarants. Here’s how it works:

Did you ever wonder how a gasoline pump knows that you’ll be able to pay for the transaction before it knows how much gas you’ve pumped? When you swipe your card before pumping, it simply “authorizes” what it considers the maximum reasonable amount that you could pump, and then “captures” the actual amount of the transaction when you’re finished. It will suffice to say that you will not likely be using this code in your eCommerce system, but if you need it, it’s there.

{mospagebreak title=Testing} Before setting up your transaction system and immediately processing live transactions, some testing of the system is prudent, for your benefit and your customers. Fortunately, provides an excellent platform for transaction testing, so your system can go live with minimal white-knuckled fear (or excitement) of incorrectly charging your customers credit cards. (Note: if you’re not sweating a little bit the first time you deploy this system in a live environment, you’re not taking the potential problems seriously enough)

The first thing you can do to test an account is to simply put the account into “test mode” on the account control panel. This will cause all transactions to be processed as tests, and no one will be charged a penny. When processing transactions in test mode, you can use the credit card number “4222222222222” (that’s twelve 2’s, in case you’re wondering), the system will return a response code corresponding to the whole dollar amount of the transaction. In other words, using the special credit card number, a transaction for $6.00 will return error code 6 from the system, “Invalid Credit Card Number”. This feature affords you the opportunity to test specific logic for handling different responses from the system.

If you don’t want to put the whole account into test mode, you can simply send a field with your transaction form with a name of “x_Test_Request” and a value of “TRUE”. This places the system test mode for a single transaction, and causes the system to behave, for the purposes of that transaction, as though the account was in test mode. This might be useful if you need to make upgrades or improvements to a live account, and wanted to be able to process test and live transactions simultaneously.

Finally, if you’re uncomfortable testing with your actual account, or you don’t even have an account, or you’re just doing this for fun, you can send your transactions with a x_Login value of “testing — an account provided by specifically for developers to use to test with the system.

I cannot stress enough the necessity of adequate testing for these transaction-processing systems. With electronic systems, it’s easy to lose sight of the fact that you’re dealing with real people’s real money. Note that it might take a while for you to prove the difference between an honest mistake and an attempt at credit card fraud. Don’t give the skeptics more reasons to not believe in the promise of eCommerce. . . test your systems adequately.

{mospagebreak title=PHP and CyberCash} While the focus of this article is on connecting to the system through a request / response interface, a discussion of eCommerce connections with PHP would not be complete without discussing CyberCash, given that there is a PHP module devoted to it. However, one of the major differences between the CyberCash system and the system is that the latter does not require anything to be setup or installed — it’s a completely script-based interface.

To connect with the CyberCash system, you will have to register at their website and download and install a copy of their Merchant Connection Kit (MCK) at your web host. Then, you will have to recompile PHP with the embedded CyberCash support to be able to access PHP’s API for CyberCash. If you’re not hosting your own site, this means being dependent on your ISP for this functionality, though more and more providers are offering it in a standard package.

After compiling PHP with the CyberCash extensions installed, you will be able to access ‘CyberLib’, a set of functions for use with the CyberCash system. However, research has shown these functions to be poorly documented and even less poorly understood by the PHP development community. The main method of integration with CyberCash is through the direct socket interface, and the purpose of CyberLib is to provide a convenient programming interface so you don’t have to get your hands dirty with socket programming. A sample transaction using the CyberLib interface to CyberCash’s CashRegister (taken straight from the PHP source code documentation) is shown below.

$merchant=””; /* Your merchant ID goes here. */
$merchant_key=””; /* Your merchant key goes here. */
$response=SendCC2_1Server($merchant,$merchant_key,$payment_url, $auth_type,array(
“Order-ID” => “2342322”,
“Amount” => “usd 11.50”,
“Card-Number” => “4111111111111111”,
“Card-Address” => “1600 Pennsylvania Avenue”,
“Card-City” => “Washington”,
“Card-State” => “DC”,
“Card-Zip” => “20500”,
“Card-Country” => “USA”,
“Card-Exp” => “12/99”,
“Card-Name” => “Bill Clinton”));
while(list($key,$val)=each($response)) {
echo $key .”=” .$val .” “;

As stated earlier, these built-in functions are poorly documented and difficult to use, and this sentiment is echoed in the user commentary with the online PHP manual at In an attempt to de-mystify the process of connecting to the CyberCash CashRegister, PHP developer Nathan Cassano has written an excellent article on connecting with his ‘CyberClass’, an adaptation of the standard CyberLib. The article, and other information about connecting to CyberCash, can be found at

{mospagebreak title=Summary} All of this text, and I’ve only scratched the surface of what is possible with transaction authorization providers such as, CyberCash, and others. All of these companies provide full-service transaction services and robust interfaces for developers to interact with them. While this article has only touched on one method of interacting with transaction services, I hope that it has shown you how easy it is to link to a verification system and provide customized credit card verification for your business or internet store.

[gp-comments width="770" linklove="off" ]

chat sex hikayeleri Ensest hikaye