Home arrow Site Administration arrow Page 2 - Script-Based Credit Card Interfaces

A Word About Security - Administration

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.

TABLE OF CONTENTS:
  1. Script-Based Credit Card Interfaces
  2. A Word About Security
  3. Testing
  4. PHP and CyberCash
  5. Summary
By: Stephen Junker
Rating: starstarstarstarstar / 8
March 14, 2001

print this article
SEARCH DEV SHED

TOOLS YOU CAN USE

advertisement
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 www.verisign.com or www.thawte.com.

{mospagebreak title=Building the Form, Making a Request} As previously discussed, Authorize.net 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 Authorize.net transaction server http://secure.authorize.net/gateway/transact.dll. 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 Authorize.net documentation, include the following pieces of information:

Information Authorize.net 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="https://www.authorize.net/gateway/transact.dll">
<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_ADC_URL" VALUE="https://www.yourserver.com/results.php">
<INPUT TYPE="hidden" NAME="x_Version" VALUE="3.0">
<INPUT TYPE="submit">
</FORM>


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, Authorize.net 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 Authorize.net 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. Authorize.net 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 Authorize.net fields that show the result of the transaction are as follows:

Information Authorize.net 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:
<?php

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:
<B>$x_response_reason_text</B>.<BR><BR>";
}
?>


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.



 
 
>>> More Site Administration Articles          >>> More By Stephen Junker
 

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort
   

SITE ADMINISTRATION ARTICLES

- Coding: Not Just for Developers
- To Support or Not Support IE?
- Administration: Networking OSX and Win 7
- DotNetNuke Gets Social
- Integrating MailChimp with Joomla: Creating ...
- Integrating MailChimp with Joomla: List Mana...
- Integrating MailChimp with Joomla: Building ...
- Integrating MailChimp with Joomla
- More Top WordPress Plugins for Social Media
- Optimizing Security: SSH Public Key Authenti...
- Patches and Rejects in Software Configuratio...
- Configuring a CVS Server
- Managing Code and Teams for Cross-Platform S...
- Software Configuration Management
- Back Up a Joomla Site with Akeeba Backup

Developer Shed Affiliates

 


Dev Shed Tutorial Topics: