Showing results for 
Search instead for 
Did you mean: 

This is part eleven of a multi-part series on handling online payments.


In Part 1 of this series we identified our goals (creating a payment form that was usable, accessible, and secure) and began by creating the form we will use to capture payment information. In Part 2 of this series we continued this process by exploring how we will handle the data submitted by that form. In Part 3 of this series we took the data received and sanitized in Part 2 and validated that it was in a format we required. In Part 4 of this series we took the errors we found in Part 3 and displayed them in a user-friendly format to minimize cart abandonment. In Part 5 of this series we processed the payment and handled the response returned to us whether it be approved, declined, or an error completing the transaction process.


In Part 6 of this series we changed our focus to improving upon our form to make it more user-friendly, secure, and easier to maintain. We accomplished this by preventing duplicate form submissions using the POST/REDIRECT/GET design pattern. In Part 7 of this series we prevented spambots and other malware from making automated form submissions by using a honeypot and form token. Part 8 of this series we used JavaScript to increase the usability of our web form making it even easier to use. In Part 9 of this series we used some HTML and CSS to enhance the layout to make the form easier to use and more visually appealing. In Part 10 of this series we refactored our PHP code to make the payment form easier to maintain.

In this installment we will make a few final tweaks to finish our form.


Placing Our Stylesheet In An External File


The last installment of this series we improved our PHP code by placing our functions in a separate file. This made our form easier to maintain by removing the clutter created by having so much code in one place. We are going to apply this same logic to our CSS rules. We will take our CSS rules and place them in a file called stylesheet.css. We will then use the HTML <link> tag to include the stylesheet in our page.


        <title>Payment Form</title>
        <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
        <meta http-equiv="Content-Language" content="en-us">
        <link rel="stylesheet" type="text/css" href="stylesheet.css">


Removing the CSS rules simplified our form by removing 62 lines of code and replacing it with only one. You will see larger gains if you create your own rules to custom the form even further then we have in this series. An added benefit of placing the CSS rules in an external file is browsers will cache the stylesheet so if the user has to return to the form for any reason, such as encountering an error or making a second purchase, the page will load faster because the browser does not have to request the stylesheet again.


Where Are The CVV Numbers?


By now you almost certainly have seen a payment form that requests either "the security code" for your credit card, also known as the CVV number. (If you are unsure of what this is, see Part 3 of this series for more information). It has become commonplace to ask for this when accepting a credit card payment online. However ubiquitous this may seem we want to err on the side of caution and assume our users do not know where to find this number. To help them along we can display sample credit cards that show where these numbers are located.


Below is the code we will use to do this (the images will be included in our sample code):


        <label for="cvv"<?php if (array_key_exists('cvv', $errors)) echo ' class="labelerror"'; ?>>Security Code</label>
        <input type="text" name="cvv" id="cvv" autocomplete="off" value="" maxlength="4">
        <img src="/images/3digit.png" width="180" height="113" alt="Three digit CVV number on the back of the credit card">
        <img src="/images/4digit.png" width="180" height="113" alt="Four digit CVV number on the front of the credit card">


Updated Payment Form


To see our new form with our new PHP code included just download the attachment at the end of this blog post. Don't forget to also download the PHP SDK.


Additonal Tips and Homework


This series may be over but that doesn't mean this form cannot be improved upon. Here are some suggestions for how you can make your own improvements:


  • Use JavaScript to disable the submit button until the user has properly completed the form. This will prevent the user from submitting incomplete data.


  • Use JavaScript to validate the form in real time. This will make your form even more responsive to the user and provide a better experience on your website.


  • Always use SSL with your payment form. Not only is it important to ensure the user's sensitive information, especially their credit card information, is safe from eavesdroppers. Just as important is that many users are trained to look for the lock icon or green address bar to see if the page is encrypted. They may not know how it is important. They just know they have to see it.


  • Consider using HTTP Headers to Help Secure Your Website. Security goes far beyond the PHP code we have written.



The Handling Online Payments Series


  1. Part 1 - Basic Information and Our Form
  2. Part 2 - Reading In And Sanitizing Submitted Data
  3. Part 3 - Data Validation
  4. Part 4 - Handling Validation Errors
  5. Part 5 - Processing Payment and Handling the Response
  6. Part 6 - Preventing Duplicate Submissions with POST/REDIRECT/GET
  7. Part 7 - Preventing Automated Form Submissions
  8. Part 8 - Using JavaScript To Increase Usability
  9. Part 9 - HTML and CSS Enhancements
  10. Part 10 - A Little Bit More PHP
  11. Putting the Finishing Touches on Our Payment Form

John Conde is a certified Authorize.Net developer