Archive for the 'Processing Methods' Category

Ever since Authorize.Net released the Automated Recurring Billing API we have had the fortunate experience of integrating quite a few gateways that utilize this new functionality. As we have delved further into the needs of each client it became apparent just how much thought must go into a recurring billing system.

At first glance the ARB API seems to be very sparse in terms of functionality and you would be right. They limit the calls to their system to:

• Creating new ARB subscriptions
• Editing existing subscriptions
• Deleting existing ARB subscriptions

So why is this new API considered so useful? Because those three ARB functions allow us to do everything we need when combined with our own recurring billing system.

So what would our recurring billing system need to do? It would need to:

1. Manage our subscription IDs
2. Track customer credit card expiration dates
3. Notify customers of their credit card’s expiration date
4. Allow customers to change the credit card associated with their subscription
5. Alter the amount of a recurring billing subscription
6. Delete a subscription

Over the next few blog posts we will explore the needs of our recurring billing subscription system and how we will use the Authorize.Net ARB API along with our own subscription tracking system to make a robust subscription application.

A common question asked online is how to accept credit card payments at a fair or market. Generally when this question is asked it is implied that the merchant will be somewhere where they can’t bring a traditional credit card terminal because they do not have access to a phone line or electricity. Naturally this represents special circumstances under which the merchant has to operate.

Naturally to get started the merchant will need a merchant account. This is discussed here and online in great detail so we won’t go into detail here. Naturally anyone needing help with that can ask for it in our forums.

There are two ways of doing this:

1. Use a wireless terminal

   A wireless terminal works just like a cell phone. Anywhere you can make a phone call you can process credit cards. Wireless terminals are self sufficient as they do not need a telephone line (they are wireless) or an external source of electricity as they are battery powered. This means you can bring it to your stand and process just as if you were n a typical retail store.

   This is great as it gives you immediate feedback about the transaction. You can complete the sale with the same level of confidence as if you really did have a true retail store. Plus by swiping the credit card through a credit card terminal you qualify for the lowest rates available from the major credit card issuers. The downside is the cost of wireless terminals. The Nurit 8000 (probably the best wireless solution out there) will run you close to $700. Plus you must pay wireless fees just like you do for your cell phone. Usually it is a flat rate per month of around $20 – $25. This is in addition to the processing fees you are already paying. Plus if you are located someone where their is no wireless signal you cannot use it. So if you travel frequently to remote locations this may not be a reliable solution for you.

2. Use a manual imprinter

   An alternative to high tech wireless terminals is the old fashioned manual imprinter. You might think we are pulling one on you but anyone who is in the credit card processing industry knows that not only have the not gone out of use but they are as important as ever. And for mobile and remote merchants they may provide the best solution to accepting credit cards.

   What the merchant would do is imprint their customers’ credit card orders at the fair/market and have them sign the imprinted credit card slip. The merchant will give them a copy as a receipt and take theirs back to your home or office. You will then manual key enter your orders into your basic credit card terminal so you can receive payment. For large or suspicious orders the merchant can call for a voice authorization on their cell phone to verify and freeze the funds on their credit card. You then can claim those funds from a basic terminal like the Verifone Trans 380 that you have back your home, office, or even hotel room.

   This is great because your upfront costs are lower then a wireless solution. Plus this works anywhere as you are not dependent on any external forms of power or communication. The downside is that you do not get an immediate response for your transactions and it is possible for a sale to be declined long after the customer is gone. Plus, if you choose to make frequent phone calls for approval, you will be charged a fee around 60¢ for each call. That is why this should be reserved for large or suspicious orders.

For mobile merchants who are not accepting credit cards in a typical environment there are no ideal solutions. But they are choices available and both are viable solutions. Do the math and decide which is best for you.

Technorati Tags: wirelss terminal, accept credit cards, Nurit 8000, Verifone, Tranz 380.

One of the biggest misconceptions out there right now is that Authorize.Net is a payment processor. Often times I will hear or read about someone who is looking for a new payment processor and a common answer is, “try Paypal or Authorize.Net”. While I am sure Authorize.Net is thrilled that they are so commonly considered by merchants as a payment solution, unfortunately by itself their product is useless.

What most people do not seem to understand is exactly what Authorize.Net offers. Authorize.Net primary service is their payment gateway. A payment gateway connects a merchant’s website (usually through their shopping cart) to their merchant account. The payment gateway takes the transaction information, passes it on to the processing bank. It then receives the results of that transaction and presents it back to the originating website so it may react accordingly. Basically, it performs the same function as a credit card terminal does in a retail store.

What is important to note about this is scenario is that without the merchant account on the other end, the payment gateway is useless. Without someone to send the transaction to the payment gateway cannot function as by definition the gateway serves to connect the website to the merchant account. Having no merchant account means an incomplete

An important reason why this is important to know is some merchants may sign up for an Authorize.Net account thinking they are getting everything they need to process credit cards online. In reality they are missing the most important piece and have even more fees in store for their business. This might not be the best option for their business especially if they will be a low volume business.

So, when you see someone recommending Authorize.Net as a payment processor, keep in mind they are only a tool for processing payments. They are not the ones actually processing the payment. That is the role of the merchant account.

Technorati Tags: Authorize.Net, payment gateway, merchant account, process credit cards

Today Authorize.Net released their API for their recurring billing feature of their payment gateway. This feature has been eagerly awaited by businesses who wish to automate the process of establishing recurring billing accounts without having to manually set up each account or, even more importantly, did not want to store credit card information of their customers until they had an opportunity to establish their recurring billing account.

Examples of businesses you could take advantage of this are:

• Webhosting
• Subscription based websites

Naturally we wasted no time and created our own class to access their API. Here is an example of how to use this class to create a recurring billing account. It should be noted that this class defaults to monthly recurring billing that starts one month from when the recurring billing account is created and will run for three years. You can change this by passing different values to the class before creating the account.


try
{
require_once("AuthnetARB.class.php");

echo $arb -> getResponse();
}
catch (AuthnetARBException $e)
{
$debug = $e->getTrace();
die("Exception occurred: " . $e->getMessage() . ". File: " .
$debug[0]['file'] . " on line " . $debug[0]['line']);
}


Hopefully this is enough to get you started in accessing the Authorize.Net Recurring Billing API. You can be sure an article will follow that will go into further detail about using this feature and API.

You can download the PDF of their integration guide from your control panel.

You can download a beta version of our Authorize.Net Recurring Billing Class here. It is written in PHP 5 but can easily be converted to PHP 4.

Technorati Tags: Authorize.Net, payment gateway, recurring billing, PHP 5, PHP 4, subscriptions, credit card

Authorize.Net will begin beta testing a new API for their recurring billing service. Currently users of this feature had to either manually configure recurring billing accounts or upload a file containing multiple accounts.

This API is slated to go live by the end of the month. We have been asked to be beta testers of this new feature. Expect a review and an article with code to follow.

Technorati Tags: Authorize.Net, payment gateway