Pivotal Labs recently invited Recurly to present a TechTalk to a room of developers. Developers are smart people and can quickly figure out how to run credit card transactions using the numerous payment gateway APIs out there. So, we decided to present a range of topics that you won't learn from reading documentation -- advice you'll only learn from experience.
In the next several weeks, the TechTalk video should become available. Until then, let me share a few of the key points with you.
The Basics: How a Payment is Routed
The credit card network is a crazy network in and of itself -- lots of banks, credit card networks, and payment gateways & they all need to talk to eachother. That's where your payment gateway comes in; your site communicates with the gateway and the gateway routes the credit card transaction to the right credit card company (who in turn routes it to the customer's bank). In the end, there's about 5-6 hops before an authorization is made -- see our article How many companies does it take to process a credit card? for more information.
In addition to a payment gateway, you will need a merchant account. The merchant account is best described as a special checking account for your business. This is where all the money you collect from your subscribers will be deposited. The payment gateway, through the credit card interchange network, coordinates withdrawing money from the customers bank account and deposits these funds in your merchant account.
Getting a Merchant Account
I think of merchant accounts as special checking accounts because they really are special. Special as in time consuming to open and full of headaches. When you collect money via credit cards, the transaction doesn't end when the money is deposited in your account. You can be liable for that money for months after the transaction is over because the credit cards want to protect the consumer. For example, if you sell $1 million of goods but then go out of business before you deliver those goods those consumers will ask the credit cards for their money back and all of a sudden you better have $1 million still in your merchant account.
If you're working a side project, or your business is going to scale up slowly, then I don't want you to waste much time on opening up a merchant account. Instead, you should look at using a service like PayPal Website Payments Pro -- it combines a merchant account and payment gateway in one, and is easier to apply for. But if you're incorporated and this is your revenue stream, you should open a merchant account with a proper bank. And, you should budget about a month for the full process of opening a merchant account and getting the credit card agreements in place.
For internet start-ups in the San Francisco area, we strongly recommend Silicon Valley Bank for merchant accounts. They understand start-ups like nobody else. Recurly spent a month trying to open a merchant account with Bank of America. Ultimately, B of A denied us because they don't understand e-commerce. This is pretty common among traditional brick-and-mortar banks.
Not every bank (merchant account) will work with every payment gateway. If there's a gateway you really want to use, make sure it works with your bank first. Along those same lines, not all integration is equal. Some banks have first class integration with some payment gateways. When a bank has a strong integration, you'll get access to your money faster, possibly better transaction rates, and better error messages.
One word of advice, be careful signing up for your payment gateway through your bank's reseller program. When your bank resells a payment gateway account, you cannot keep your gateway and switch merchant accounts! This is so incredibly important. If you store your credit cards with your payment gateway and your bank decides to close your account for any number of reasons, you no longer have access to your credit card information. It's totally not worth the $200 savings off the payment gateway setup fee. Seriously, this happened to me and nearly killed the company's revenue.
If you're looking for a gateway that understand technology well, take a look at Braintree Payment Solutions.
Maximizing Acceptance Rates
Address Verification (AVS) is old school. Perhaps it works differently across different payment gateways but my experience with Authorize.Net's AVS suggests that this is old school 1960's string matching technology. Zip code validation only works reliably inside the US -- it almost always fails on alpha characters. So, if you accept international payments, make sure your AVS will succeed on street address matches OR zip code matches, if the customer's bank supports AVS. That setting will help you minimize fraud and maximize acceptance rates.
If you're only conducting business in the US, you can turn up AVS more if you like. This advice is critical if you want to accept international transactions and minimize headaches.
Here's an industry secret -- expiration dates usually don't matter as long as they're in the future. Several years ago, the credit card companies and utility companies came to an understanding about expiration dates -- it's much easier to setup auto-pay for recurring payments if the expiration date doesn't matter. The banks understand that if your card is stolen, they can just change the number -- there's no point in having it stop working because of an expiration date.
If you store the expiration date with the credit card information in a payment gateway (e.g. Authorize's CIM), that card will stop working after the expiration date. You cannot move it forward unless you collect the user's credit card number again. But if your billing system is smart enough, perhaps it can try moving the current expiration date forward before asking the user to update their payment details when the card expires.
1 Cent Authorizations
If your payment gateway allows you to test a credit card with a 1 cent authorization, don't use it. Seriously. It will fail 2-5% of the time. Some banks can't believe anyone would want a 1 cent payment so they will deny it for being too small. Instead, either use a $1 authorization or authorize the transaction for the amount you want to collect in the future (if you know exactly how much that is). And finally, void the authorization afterwards. If you don't, the credit card companies may hit you with a fine -- this is becoming more common since an authorization effectively puts a hold on funds in the customer's account and they want you to release it if you don't intend to collect.
Keep Your Pricing Simple
If you have a great product, your customers will want to pay you. But if your pricing is too complicated, three things happen:
Your sales guy can't explain pricing,
Your programmers (you) will spend too much time figuring out how to bill your users, and
Your customers will complain that they're paying too much.
Simplify your pricing, perhaps replace overage fees with auto-upgrading tiers, and magic happens:
Your sales guys can explain it in a minute,
Your programmers (you) will spend less time on billing, and
Your customers will be happy to pay.
Minimize Your Time Handling Billing Support
Billing support will overwhelm you if you're not ready. Make sure your users can self service their accounts the moment you start charging. If you offer more than one billing cycle or pricing plan, allow your users to change their plan with minimal hassle -- otherwise they're going to write to your support and you'll have to do it for them, and often.
Make it easy for your subscribers to cancel. They should not have to contact you to stop paying you -- in the end they'll just be more likely to call their credit card company and dispute the charge (that's a chargeback). And if you collect enough chargebacks, say goodbye to your merchant account.
Finally, if you build your own subscription billing system, you're going to spend disproportionate amounts of your time handling past-due accounts. You'll get up and running quickly with your payment gateway's recurring billing API, but you'll spend 10x more time trying to figure out how to handle an account when a payment fails. That's precisely why we created Recurly.