Merchant Account Services

Integrate the Authorize.Net Payment Gateway with PHP

Integrate the Authorize.Net payment gateway seamlessly into your ecommerce website

 

Author: Jim Conners

Rating: 10.0

Pages: 1|2|3|4|5|6|7|8|9|10

Planning the Transaction

Before we start to tackle processing the credit card payment programmatically, we should have an understanding of how the customer data flows from the beginning of the process (they submit the form) to the end of the process (they are informed of the success of their transaction). This will not only give us a better understanding of how an online payment works, but will also allow us to plan for contingencies like a processing error or declined transaction. Below we will follow customer data from submission through completion.

  1. Capture Customer Information

    The transaction process begins with the submission of the customer data including their credit card information. At this point you should validate it and, if there are any errors, return the user to the checkout page and ask them to correct any errors. If the information is correct you will need to prepare it so it will be in the format Authorize.Net is expecting (you may ask the customer for the information in one format that is easy for them to understand, but that may not be compatible with the parameters Authorize.Net is expecting).

    What we'll need to do:

    • Receive customer submitted data
    • Validate all customer submitted data
    • Inform the customer of any errors
    • Ensure all data is in proper format for submission to the Authorize.Net API

  2. Send Data to Authorize.Net

    Once you have validated the data submitted by the customer and have ensured it is in the proper format Authorize.Net is expecting you will need to send it to them via their API. Authorize.Net then passes the transaction information on to the processing bank associated with the merchant account linked to this instance of the gateway. The processing bank will send a response back to Authorize.Net including whether the transaction was approved and the results of AVS.

    What we'll need to do:

    • Connect to the Authorize.Net API
    • Send the transaction data

  3. React to the Response

    Upon successful communication with the processing bank Authorize.Net will return a response to your application. There are three possible responses that we will need to deal with:

    1. Approval/Success

      The transaction was approved by the processing bank. The merchant will be credited with their funds in a couple of business days and the customer will see the charge on their next credit card statement.

    2. Decline

      The transaction was declined by the processing bank. For reasons known only to the processing bank, meaning you cannot find out why the transaction was declined, this sale was declined. The merchant will not get paid and the customer will not be charged.

    3. Error

      Somewhere between your application sending the transaction data to Authorize.Net and your application receiving the data back an error occurred. The transaction was not processed and cannot be considered approved or declined.

    Each result will require a different response by your application:

    • Approval/Success

      At the very least your application should display a message indicating the transaction was successful. Ideally your application will present the customer with a printable receipt that they can keep for their records and a confirmation email will be sent as well.

    • Decline

      Because the transaction was not successful we essentially can consider it to be an error. It would be no different then if the customer entered incorrect information into the order form. The customer should be informed of the results of the transaction and be offered another opportunity to pay using a different credit card.

      Tip: You may want to store the credit card information into a session variable and compare it to the new credit card information submitted by the customer. If they match you should flag it as an error without ever sending it to the gateway to be processed. Since the odds of it being declined twice is very high, almost 100%, you can save money by not incurring a transaction fee for the new declined transaction.

    • Error

      There are a variety of reasons an error can occur. Since most of them are out of our control and beyond the scope of this article, we'll only concern ourselves with how we might handle them. Basically we have two options:

      1. Try Again

        Temporary connection errors and other various errors happen from time-to-time and there is no reason one won't occur while trying to process a transaction. Just like any other computer error there is no harm in trying again. And considering a sale is at stake it makes sense that we will try again. Trying again is as simple as re-sending the transaction information back to Authorize.Net.

      2. Inform the customer of the error

        Repeated processing errors is an indication that a transaction will not be successful. This does not mean the sale will necessarily be declined, but unfortunately something beyond your control is preventing the transaction from being processed properly. At this point all you can do is inform the customer of the error and invite them to make payment in an alternate way (e.g. Paypal, or by telephone).

    What we'll need to do:

    • Receive the response from Authorize.Net
    • React to the response based on the results of the transaction

Authorize.Net | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | Building our Class