Handling Online Payments With PHP And Authorize.Net

As a frequent poster in Authorize.Net’s Developer Community Forums I am exposed to developers of all skill levels. They range from the inexperienced to the very experienced. It was the inexperienced users that caught my attention, though. Seemingly every day a new developer was asking questions that indicated that they did not understand best practices for developing an ecommerce application. I attributed this as due, in part, to the fact that the majority of tutorials related to programming does not use best practices nor a realistic scenario of how a technology will be used.

So, as an Authorize.Net blogger, I decided to write a series of articles that outlined not only the basics of handling an ecommerce transaction, but also included some best practices as well. These were demonstrated using a web-based payment form that when complete forms a real-world, production ready solution.

Since there was a lot of ground to cover, I broke the tutorial into eleven parts. Each part built upon the changes we made in the previous article. Each article also included the source code for our payment form. At the end of the series the final code is made available and I have linked to it from the bottom of this article as well. Below is a link to each article and a summary of what it covers.

  1. Part 1 – Basic Information and Creation Of Our Form

    We get the series started by determining what information we will need from our users to complete the payment process. With it we will start to construct the HTML form we will use to capture that information.

  2. Part 2 – Reading In And Sanitizing Submitted Data With PHP

    In the second installment of the series we take the form we created in part 1 and show how to properly receive and sanitize the information using PHP.

  3. Part 3 – Data Validation

    In the third installment of the series we take the data we sanitized in Part 2 and validate it to make sure it contains the values we expect in the proper format.

  4. Part 4 – Handling Validation Errors

    In the fourth installment of the series we take the errors generated by invalid data we found using the PHP code we added part 3 and display them in a user-friendly and intuitive way.

  5. Part 5 – Processing Payment and Handling the Response

    In the fifth installment of the series we move past receiving, sanitizing, and validating data and get to the nitty gritty of processing the payment using Authorize.Net’s PHP SDK.

  6. Part 6 – Preventing Duplicate Submissions with POST/REDIRECT/GET

    The payment form we created in the first five parts of this series is very good. But it could be better. Part 6 begins a new chapter in this series where we improve upon our payment form to make it more usable, secure, and maintainable. We begin by preventing users from making duplicate form submissions by using the POST/REDIRECT/GET design pattern.

  7. Part 7 – Preventing Automated Form Submissions

    In the seventh installment of the series we continue to improve upon our form by increasing our security and reducing fraud by preventing bots from automating form submissions.

  8. Part 8 – Using JavaScript To Increase Usability

    In the eighth installment of the series we continue to improve upon our form by using JavaScript to increase the usability of our form. The JavaScript used in this part is based on the Prototype JavaScript framework.

  9. Part 9 – HTML and CSS Enhancements

    In the ninth installment of the series series we use HTML and CSS to enhance our form’s appearance and increase usability even more.

  10. Part 10 – A Little Bit More PHP

    In the tenth installment of the series series we refactor our PHP code to make it better organized and easier to maintain.

  11. Part 11 – Putting the Finishing Touches On Our Payment Form

    In the final installment of this series we make a few more minor changes and present additional tips and ideas for improving upon our payment form even more.

Get The Code

The code used in this series is available for download from the Authorize.Net Developer Blogs. I’ve linked to it below for your convenience. The PHP SDK not included in the sample code to ensure you get the latest copy which includes any bug fixes since this series was originally written.

  1. Download the payment form
  2. Download the PHP SDK

Related Posts:

17 thoughts on “Handling Online Payments With PHP And Authorize.Net

  1. John, what a fantastic reference this blog is. You’ve helped out a lot of people, I’m sure.

    I really love the classes you’ve provided for AIM and ARB … my question is this:

    What’s the difference between the class you’ve provided and using the solution above with the PHP SDK? Are they essentially the same thing? I was thinking that I would just use the AIM class to initiate the first payment and then the ARB class to create a subscription…

    Thoughts?

  2. This class is very different then the PHP SDK. The PHP SDK is a very robust solution provided by Authorize.Net. But it comes with a lot of overhead as it offers solutions for every API Authorize.Net offers with each solution having it’s own dedicated codebase. My classes are dedicated to each API which make them lighter and easier to use on their own. I’m currently working on a new class and tutorial that would take that a step further and have one class for all of their XML APIs (AIM, ARB, CIM and Transaction Details) that is even lighter and easier to use.

    Their PHP SDK is more powerful, my classes are lighter, but both get the job done. Use whichever you find works best for you. I’ve used my classes in countless integrations so I probably will never switch away from them but I am also probably biased.

  3. John, thanks for your reply.

    Would you recommend processing the first transaction with the AIM class and then *if success* create a subscription? It’s been a while since I used the Auth.net API, but that’s how I remember having to do it in the past.

    Again, your blog is a major resource. It’s very much appreciated!

  4. That’s exactly what I would recommend. That way if the card is declined you will know immediately and can have the user try a new card. If you only use ARB then you have to wait until the first subscription payment is processed later that evening and if it fails then you have to hope you can get the user to come back to your website and update their credit card information. That’s much less likely to happen.

  5. Thanks John, it’s nice having the validation.

    One other thing I was going to ask was: when submitting the ARB request, do I need to pass the user details again if they just submitted an AIM transaction? Couldn’t I just pass their ID and skip the “duplicate” content?

  6. Unfortunately not. The two aren’t connected so you will need to pass everything again to actually create the subscription successfully.

  7. I’m currently working on a new class and tutorial that would take that a step further and have one class for all of their XML APIs (AIM, ARB, CIM and Transaction Details) that is even lighter and easier to use.[/blockquote]

    John, what is the ETA on that class and tutorial?

    I would love to put together a class that automatically integrates both the AIM and ARB APIs. To be able to setup a product (or several) that can be either paid in full, or split up in payments. Depending on what the user chooses, the class is able to process it all accordingly… perhaps with session management (for repopulation) built in.

  8. John, thank you so much for this wealth of information.

    I am trying to incorporate the AIM method into an existing site. Where
    I’m having difficulty is in passing the various field info via “” from the previous page in order to pre-populate the billing fields. The “if (‘POST’ === $_SERVER[‘REQUEST_METHOD’])” is causing validation errors right away for the shipping fields as well as the honeypot and token.

    I’ve tried using “if ($_POST[‘submit’])” instead but then I can’t get the fields to properly populate after the submit button is clicked.

    I suppose I could force populate the shipping fields from the billing fields upon entering the page.

    I apologize if this is confusing to understand. I just thought I could get this going fairly quickly but I keep running into problems. Any suggestions that you may have would, of course, be greatly appreciated.

    Thanks again.

  9. John:

    I’m currently working on a new class and tutorial that would take that a step further and have one class for all of their XML APIs (AIM, ARB, CIM and Transaction Details) that is even lighter and easier to use.

    Were you ever able to create this class? Perhaps you have and I’m just not seeing where it’s been posted… :)

  10. hi John,

    I am working as webdeveloper in dubai, here i am using the credit card puchasing system , I think paypal not supported currency AED, is authorize.net support AED currency or usng authorize.net we can do ?

  11. Authorize.Net only supports US dollars so you’re only option is to convert to US dollars before doing your transaction. There are currency conversion APIs out there that should make ths easy for you to do.

  12. I have question , Please tell me list of credit cards that authorize.net accept. Thanks in advance….

  13. @nivas To use AED in your website, you should consult to your near bank , you will use their payment accept service to accept AED dirhams.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>