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.

Payment Gateways

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

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.

Expiration Dates

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.

TechTalk Slides

1. Signup for a recurring billing service
2. Create a signup form that accepts the billing information
3. Create a page for the user to update their billing information
4. Allow the user to cancel their subscription
5. Sell your product or service and money

The above will get you up and running with subscriptions.  However, there’s a lot missing from the above picture that you won’t realize until you roll out your new billing system.  If your startup is new to subscription billing, there are a few key problems you’ll soon encounter.  Knowing about these issues will help you budget your development resources appropriately and help you evaluate your recurring billing options.

Declined Recurring Payments
For starters, what happens when one of the recurring payments fails due to a declined or expired credit card?  Will your system know to alert the user and/or cancel their subscription?  Can you get a list of past due accounts?  And, will the system continue billing the user or will it stop until their payment information is updated?

When a card is declined during the subscription renewal, you need to alert the customer and give them a way to update their billing information.  If they update their billing information in a timely manner, then bill them the missed amount.  Otherwise, the appropriate action is to cancel their subscription and transition their account back to a free account.  Unfortunately, many recurring billing APIs make it non-trivial to determine if a recurring payment failed.  And, if the user updates their billing information, verify that the service will collect the missing payment — this should happen immediately as part of the billing info update process.

Upgrades and Downgrades
If your site offers multiple subscription types, billing intervals, or quantities, then your customers are guaranteed to ask for upgrades and downgrades of their subscription.  If you start offering your subscriptions without a means for the subscriber to modify their own subscription, then you’ll receive several support requests.  Hopefully your support staff has the tools to modify the subscriptions or else you will miss the opportunity to make more money by allowing your users to upgrade.  And, a few users will be more than unhappy.

Of course, not all recurring billing APIs will allow you to upgrade or downgrade like you would expect.  Typically, an upgrade (additional quantity, add-ons, or service level) should happen immediately.  To do that, the remainder of the current term needs to be prorated and billed immediately.  Not all recurring billing services do this — some will require you to wait until the renewal to charge a new amount.

Downgrades or billing cycle changes can be just as tricky.  These events typically occur at the end of the current billing cycle, since the customer has already committed to paying for their current term.  These changes are doable with almost all recurring APIs, but most services will require you to perform the calculations to get the changes just right.  Buffer for some development time and lots of testing here.

Customer Service Tools
Does your billing system give your support staff the ability to lookup and modify accounts?  Your subscribers will want you to make changes (either by contacting you with a phone call or email) on their behalf.  If it takes an engineer to make subscription changes because you haven’t built the tools for your support staff to handle the modification, then you’re not using your resources efficiently.  Other users will expect your support staff to be able to offer them credits or refunds if something should go amiss.  Your support staff should be able to handle these requests immediately to minimize any chances of chargebacks or upset customers.  I strongly encourage you to give your support staff the tools necessary to support billing requests without involving a developer with database access.

Reporting and Metrics
Are you tracking your subscriber metrics?  Your payment gateway will tell you about the dollars and cents moving through your account but it doesn’t know anything about subscribers.  You’ll want to know as much as you can about new signups, upgrades and downgrades, cancellations, missed payments, failed subscribe attempts, etc.  Out of the box, most recurring billing services fail to provide these reports.

When you enter your credit card on a website, it sends the credit card information over an encrypted channel to a payment gateway. The payment gateway’s primary responsibility is to authorize payments and communicate with the merchant’s bank. Banks communicate with the payment gateway using a proprietary network and/or protocol.  Since your website is not processing billions of transactions a month, your bank does not want to integrate with you.  So, the payment gateway effectively becomes the middle man.

However, if the merchant bank is small (compared to a bank like CitiBank, Chase, or Bank of America), the merchant bank likely uses another company to communicate with the payment gateway.  This middle man is known as a merchant service provider.  Unless you run into some very tricky problems authorizing transactions, you are not likely to know this company exists.  In most cases, the merchant service provider does their job and stays completely in the background.

Now that the merchant bank has the transaction information, it routes the details to the customer’s credit card company — Visa, MasterCard, Discover, American Express, etc.  Since Discover and American Express are usually issued directly to a customer (and not through an issuing bank), these card companies return an authorization or declined message.  Otherwise, the credit card company must now connect to the customer’s credit card issuing bank.  Finally, the customer’s bank can authorize or decline the transaction and the message routes all the way back to the originating e-commerce site.  On average, the whole authorization process can take 2-3 seconds due to all the parties involved in the transaction.

To summaries the authorization flow, the credit card information goes from the user’s browser to the e-commerce website to the payment gateway (optionally) to the merchant service provider to the merchant bank to the credit card company to the user’s bank for approval.

At the end of the day, the merchant’s bank must settle the transactions (assuming the funds were captured, or approved for transfer).  The merchant bank then works with the credit card company and users’ banks to transfer the funds.

What happens if my business grows?

When you sign up for a merchant account, your application details the typical transactions you’ll process.  If you’re a start-up and you experience a rapid growth (good for you!), then you may be in for a surprise.  Banks scrutinize their merchant accounts continuously.  As part of that process, they’ll actively profile all your transactions.  If there’s a sudden spike in dollar amounts or the average transaction amount changes, the bank may review your account.  Or, they may not be so nice and you’ll receive an account termination or suspension notice.

If your business is like 97% of e-commerce sites out there, your income stream will be pretty steady and this isn’t a concern.  If your company is an internet start-up and the sky’s the limit, your initial revenue stream is going to be unpredictable.  Be upfront with your merchant account provider and ask about the review process should your transaction profile change.

If I offer yearly subscriptions, do you gradually release the funds or are all the funds available immediately?

Recurring revenue is great, that’s the beauty of selling a service.  However, the merchant account bears a small risk when you charge upfront for that service.  If you’re renewing the subscription on a monthly basis, the risk is pretty minimal and your merchant account will be happy.  But your most dedicated customers may want to pay upfront for a yearly subscription and get a little discount.  That’s great.  Be sure to ask your merchant account how this revenue is treated.

When you collect payment upfront for a year, the merchant bank is liable for those funds for duration of the year.  Ideally, your company is established and your merchant bank will release the funds immediately.  However, your bank may not do that if you’re a start-up.  In that case, ask if the yearly subscriptions can be released 1/12th every month.  That will certainly make your bank more comfortable with your service and less likely to freeze the entire merchant account, should a red flag ever be raised.

Who owns the payment gateway account?

When you sign up for a merchant account, the bank will likely be a reseller for a payment gateway (like Authorize.NET or CyberSource).  And, they’ll likely be able to give you a discount on the setup fee for the payment gateway, in addition to handling some paperwork for you.  Sounds great.

What happens if you ever need to change merchant accounts? You’ll likely need to open a new payment gateway account too.  When a reseller sets up the payment gateway account, they own the account and it cannot be updated to point to a different merchant account as part of that setup.  If you open the payment gateway account yourself, switching merchant accounts at a later date is not an issue.

Of course, this usually is not much of an issue if you’re a typical e-commerce site and you’re processing a bunch of one time transactions.  If you’re accepting subscriptions and you depend on your payment gateway to securely store your credit card information for your recurring billing, then it’s a problem.  If you ever switch payment gateway accounts, your subscriptions will stop working.  Now, that’s important.

Is there an intermediary (Merchant Service Provider) between the merchant account and the payment gateway?

If you sign up with a fairly large bank for your merchant account, they may communicate directly with the payment gateway.  If your bank is a little smaller, they may use an intermediary, known as a Merchant Service Provider, to communicate with the payment gateway.  While in most scenarios this really does not matter, the intermediary may introduce a little more lag into the communication and it may cause some variation in the error messages returned from the payment gateway.

In one scenario that I have seen, switching a merchant account while keeping the payment gateway the same introduced a new error message; “Invalid configuration in payment gateway.”  Investigating this error message was a major headache as multiple parties were involved in the transaction and each pointed the blame at someone else without identifying the problem.  In the end, we found that all the credit cards we investigated with this error were legitimately declined by the end user’s bank.  Due to the various parties involved in the transaction, the real reason for the decline was lost in translation and we were left with a generic message.