Payments Part III: The Final Frontier

September 17th, 2008 Chris

Sorry I’m late with this post … I have to admit that I’ve been a bit distracted with a bad couple of days in the financial markets. Merrill – gone. Lehman – gone. AIG – terminal. All because of the credit crunch.

So let’s get back to how we can use credit to put more borrowed money into the hands of the banks. What could go wrong?

In this final installment, we’ll look at the back end credit card processing. We’ve already covered how we collect orders from customers via the store front and shopping cart.

Payment Gateway

As I mentioned previously, think about the Payment Gateway as the virtual equivalent of the Point of Sale device at your local retail store. It gets the order information from your shopping cart and confirms the good standing of the credit card. If the Payment Gateway is happy, the order is processed and you’ll get your money. If the order is rejected, then you’ll get a failure notice and the user will be told that their order has been rejected.

Don’t worry – all that user interaction is managed by the shopping cart software behind the scenes. You just need to tell the shopping cart which Payment Gateway you are using along with your Payment Gateway account number.

Gotcha Warning – You need to make sure that the Payment Gateway you use is compatible with the Shopping Cart you want to use. My recommendation here is to pick the Shopping Cart first and then figure out what Payment Gateways it supports.

What are the factors in choosing a Payment Gateway? Here, I believe, size matters. When we chose ours, we picked the most established Payment Gateway supported by the shopping cart because that would mean the least risk that the integration with would ever break. The reality is that whenever you connect two pieces of technology, a change on either end often breaks that integration. By picking the biggest Payment Gateway, the risk that something goes wrong with the connection to the shopping cart is minimized (the prospect of all those angry customers ensures that a lot of diligence is taken in making sure nothing ever breaks).

We picked Authorize.net – one of the biggest in the business. In general, most of the big Payment Gateway companies have similar features – most of which we don’t use. One thing to note that is if you also process telephone orders, you’ll want to make sure your Payment Gateway has a “virtual terminal” which allows you enter order information directly into the Payment Gateway via your computer (instead of having to call it in yourself – a pain).

If you are doing physical orders, you have two choices: use the “virtual terminal” per above or get a Point-of-Sale terminal. For the sake of brevity (err… at least not so much longevity) I’ll ignore the latter.

Gotcha for “foreigners” – something thing to watch for you international operators (ex. Canadians selling in the $US), is that multi-currency operation is a large pain in the neck! Most Payment Gateways (especially not affordable ones) only operate in one currency. Authorize.net, for example, only operates in $US. That means, for us, all our prices are in $US and everyone’s cards are charged in $US.

There are some higher end Payment Gateways that do support multi-currency, but they are much more expensive and don’t have the same shopping cart support. Another option is to set up separate Payment Gateways – one for $US and one for $Cdn (or other foreign currency). This implies that you need to be able to set up your shopping cart to use multiple Payment Gateways, which many can do.

My recommendation: keep life simple. Pick one currency. We do get customers occasionally complaining but we’ve never lost business because of it…

Merchant Account

A Merchant Account is used to pass the actual money between the card holder’s bank and your bank. They also provide the Payment Gateway with information on the status of the credit card which is used to accept or decline transactions.

A single merchant account is used for Visa and MasterCard. In most cases, a merchant account can be applied for and obtained through your Payment Gateway provider which makes it convenient to get. If you want to use AMEX, then you will need a separate merchant account directly from AMEX (you can go to their web site and apply on-line.

Merchant Account allows you then to receive proceeds from the credit card transaction and have them deposited directly to your bank account.

Gotcha for “foreigners” – If you are doing business outside of the $US, you can only accept $US Amex cards if you have a physical presence (i.e. an office) in the $US. If you don’t, perhaps it’s time to call your buddy down South and ask him for a favour (note – to complete the illusion, spell it f-a-v-o-r). But wait – there’s more! You also need a $US bank account physically in the States for AMEX. We got the help of our banker at RBC to help us open one in Florida through their U.S. subsidiary, Centura. Another reason to bank with RBC – they are great for small business…

Gotcha for “foreigners” – What – another one? Yup. To accept $US from Visa and MasterCard, you need to have a $US currency account. The good news is that it can be physically in your country which is easily done at most banks. To support this, you need to work with a Merchant Account provider in your country, Here in Canada, we chose Paymentech.ca - a subsidiary of Chase.

If you don’t get a Merchant Account from your Payment Gateway provider, make sure you understand the Payment Gateway compatibility requirements. To make a long story short, each Payment Gateway provider supports certain processing platforms and you need to make sure that your Merchant Account provider supports them. Did you head explode? Mine did when going through this ourselves. I just copy and pasted the requirements and emailed it to our Merchant Account provider and asked “OK?”.

Once you’ve done all this, you’re good to go! Although you may be left with the distinct impression that it’s just not worth it…

Last Thoughts

While it does seem complicated, much of the complications arise from multi-country operation.

If you’re in one country, I would simply follow the recommended vendor chain: pick a Shopping Cart. Many of them offer payment gateway and merchant accounts solutions that they resell from others. Take advantage of it. If they don’t, ask the top 2 vendors of each type that they recommend.

If you’re operating internationally, the first decision is if you think you need to operate in multiple currencies. If you can live with just one – do it. Also think about if you need AMEX – it does complicate life but depending on your target market, you’ll need to have it.

You’ll note I really haven’t talked much about price. Shopping Cart pricing varies a fair bit, and that needs to be a factor in your evaluation. For merchant account providers, we found that with just a bit of negotiation, they match each others pricing – although your pricing will be dependent on the specific financial situation of your business. Finally, Payment Gateway pricing seemed to be pretty consistent… I’d also apply my “fire your suppliers” strategy to these vendors as well – just make sure to watch for any “setup” and “disconnect” fees which may make it harder to switch.

In the end, setting this up is a pain, but a necessity. Like it or not, credit cards are the life-blood of most micro businesses.

C.

Posted in Payments | No Comments »

Payments, Part II: The Cart Strikes Back

September 11th, 2008 Chris

First of all, don’t even think about asking me to explain the post title. I’ve got no idea – just kind of reminded me of Star Wars.

Last post, I gave an intro to all the working parts of online credit card processing. Sounds complicated? It is and the good news is that today, I’ll cover the easy part: the storefront and the shopping cart.

Storefront

As I’ve mentioned before, I’m pretty anal about how we present ourselves to our customers so our #1 requirement here was to be able to look very professional and do service to the different products and services we offer.

Because we don’t offer that many things to purchase (less than 20), the easiest thing for us was to design the storefront ourselves. That is, to create the web content for each of the products along with the necessary descriptions.

Where this won’t work is if you have a large number of products where it just would be too labour intensive to code up content for each page. Think amazon.com and all those books – their web pages are all database driven. That have entered raw product info and when you search for a particular book, it grabs that data and generates the web page on the fly.

You can purchase storefront software solutions. When I say software, I mean both that some can be hosted somewhere else where you load your product data up and it is presented to your customer on their site, while some you install on your own web server and load up the product data locally.

My advice here is that if you don’t have a huge stable of products, go with your own storefront and don’t buy a product. It’s much easier to integrate into the look and feel of your brand and you’ll save money…

If you’re interested, you can see what our store looks like – and please feel free to buy something while you are there…

Shopping Cart

Once someone is interested in a product in your storefront, they click “Add to Cart” or “Buy Now” or whatever button you’ve implemented. That button contains a link to the shopping card which indicates which product is being added. This sends the product to the shopping cart where is held until the user checks-out (i.e. pays) or leaves. Here is an example screen grab from ours:

Forget doing this puppy by yourself – too complicated… You need to go out and get one (and there are many, many different carts). Just try googling shopping cart and stand back.

One that I can recommend (because we used to use it) is 1ShoppingCart (www.1shoppingcart.com). It is pretty reasonably priced ($35 to $100 a month) and had all the features we were looking for. The only reason we still don’t use it is that we went with a single solution that does other things our business also needed.

What features you ask. Well, we learned from experience what we wanted in a shopping cart. A well equiped shopping cart can be a sales engine itself. Above and beyond simply gathering selected products, showing the price and then taking payment information, we wanted to be able to do things like:

• Support both one-time purchases as well as subscriptions (example, $20 per month). The latter can be complicated as the software needs to remember to charge the user’s credit card each time.
• Calculate shipping and taxes on the order. Regardless of where you are, someone government probably wants a slice of your sales. We just wimp-out ourselves and say that all tax is included, then back it out when we do the books.
• Coupons, Discount or Promotional offers. If you want to promote a product, you can provide certain users with a code they can enter to get that discount. Very important to have…
• Upsell. The ability, based on what products are in the cart, to recommend other products at the time of check-out.
• Email receipts and invoices. Be able to automatically generate and email out the necessary invoices and receipts for customers so you don’t have to worry about it.
• Email auto-responders. Once someone has bought something, triggering a follow-up set of emails can be very powerful. You can get feedback on the product and/or offer them another upsell.
• Customization. The ability to customize the look and feel so that even if the user has gone to a different site that hosts your shopping cart, they’ll have the same experience. In short, you want your shopping cart page to look like your web page – even if they’re hosted in different places.

As I said, there are many products out there. If you’re looking for both a storefront as well as a shopping cart, the good news is that most storefront solutions include a shopping cart so you won’t have to implement two different things.

There are some other considerations which you must look at before finalizing your decision on a shopping cart. It must be compatible with the rest of the payment processing chain. More on that next time…

What’s Next

Next time we’ll talk about the even more confusing world of payment gateways and merchant accounts. Now it gets interesting. OK, I realize that this stuff may be considered quite far from interesting but if you’ve got to do it, hopefully this helps…

C.

Posted in Payments | 1 Comment »

Payments Post-Grad, Part 1

September 9th, 2008 Chris

I must confess that I am a bit of a geek. I actually enjoy a technology challenge when there is a problem to be solved in our business, and I have to be a bit of a Macgyver to sort it out.

I’ve never actually worked as an engineer or software designer, despite my engineering degree. However, in the various places I’ve worked, I’ve had to become proficient in the technologies associated with the work. It’s been a necessity and I’ve usually picked it up relatively quickly.

So when I joined our micro business, I was feeling pretty confident. Whether it be upgrading to a new CRM system, setting up the office network or updating our web site, I was able to rise to the task and get it done.

That is, until a problem so complex, so insidious, that it put my technology prowess to shame. What was most embarrassing is that I knew that thousands, even millions of people had already sorted it out.

I’m talking about accepting credit cards on the web.

I was recently asked by a colleague of Colleen’s about how hard it is to set this up and I was a bit embarrassed to say that I probably spent two weeks figuring it out. Our situation was especially complicated as we are a Canadian company who operates in U.S. dollars.

So, in the next couple of blog postings, I’ll try to provide a detailed look on what it took for us to go from accepting credit cards on the phone, to accepting credit cards on line. Fasten you seat belts… it’s a rough ride.

In the beginning…

Like many micro businesses, we accepted payment in one of two ways. We could process orders by phone by taking credit card payment information by phone or fax, then calling in to our credit card processor.

For on-line orders, we used paypal. It was very convenient although you pay for that convenience… Not to mention that as a Canadian company, we could not process AMEX cards from the U.S.

Our requirements:

I think we’re representative of many online businesses. We want to use our web site to sell products and services (I’ll refer to them all as products going forward). Specifically:

• Present our products online with one-time payment and on-going payment plans (ex. five payments over five months, or $x per month in perpetuity).
• Have customers select one or more products and be presented with a final bill for confirmation.
• Allow customers to specify a particular credit card, along with personal info, and use it to pay.
• Have that payment processed and deposited into our bank account.

What you’ll see definitely added to our headaches was accepting American Express cards. They do things differently than Visa or MasterCard. But for us, AMEX made sense since many of our products are purchased by individual sales persons in medium to large companies where AMEX has very high penetration as the corporate credit card. As it turns out, about 10% of our credit card business is on AMEX.

Definitions:

Today, I’ll start by providing a quick set of definition of all the moving parts so we can see what needs to be considered when implementing this. Yes, this list of definitions you need to know is way too long – just another sign of how complicated this is…

Storefront – This is the component that displays the products that you are offering your customers. Think of going to a web site and seeing the various products being offered, where you can select them to get more information or add them to your shopping cart.

Shopping cart – This is the component that collects the list of products that the customer has indicated an interest in purchasing. It includes a product catalogue, allowing the user to be presented with order information on each product selected like price, part number, additional product details, etc… It also collects or retrieves customer information that is necessary to process the credit card (card type, card number, name, billing address, etc…) and other functions like shipping (shipping address, shipping method, etc…).

Payment Gateway – In a physical store, think of this as the point-of-sale device with which your credit card is wiped and subsequently goes off to ensure that your credit card is valid and in good standing. In the online world, it is a service that receives payment information and talks to the back-end card companies to make sure all is good and you can accept that card.

Merchant account – Think of this like a bank account- but not from your bank necessarily. Obtaining a merchant account allows this bank to give you money for the credit card transaction while it deals with processing the funds with the card-holder’s bank in the back-end.

Your Bank – This one is mercifully easy. It’s where the transaction proceeds get deposited. As long as an account with the same currency as your payment gateway and merchant account. And as long as it’s in the U.S. if you want to accept $US AMEX cards. And as long as… Never mind. So much for mercy…

Next

In the next post or two, I’ll go through our lessons learned as we actually implemented this. I’ll also look at the particular challenge for a micro business not located in the $US that wants to accept $US credit cards.

I won’t focus on all the behind-the-scenes stuff that happens in credit card processing (which I don’t pretend to fully understand). Instead, I’ll hopefully give you practical tips that will make it easier for you to actually implement.

C.

Posted in Payments | No Comments »