Recently there’s been a lot of controversy and talk about the way merchant banks provide merchant accounts. You might have seen the article TechCrunch posted about Fabulis and the fallout from Citigroup suspending their account for “nonexistent objectionable content”.

This highlights one of the major surprises that a lot of online businesses find out- merchant accounts are _not_ like personal bank accounts. As my co-founder Isaac has mentioned “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.” These headaches usually involve the major differences between online purchases and offline purchases.

Online transactions typically are services that do not include a physical exchange of good. As they are somewhat intangible, many merchant banks put these type of transactions as high risk and often request several years of payment history to prove you are a valid business (obviously if you’re a new startup, this is an issue).

What can you do?

The most important part is to choose a merchant account provider that understands online billing. Many of our Recurly users and colleagues have had great success with Braintree as they’re focused specifically on online business. We also have had good luck with Silicon Valley Bank. We’ve gotten a lot of poisitive feedback from our EU users about Wirecard. Regardless of the merchant account, be sure to ask these questions:

• How much are you paying above interchange rates? (Interchange rates are the standard fees to run a credit card)
• What are the monthly minimums? Are there invoicing or statement fees?
• When do we have access to our funds? This can be a real issue when collection yearly subscriptions. Other times it matters if they require a minimum amount in your account (revenue equal to the past 30 days of transactions).

Please also see our post on how to choose a merchant account. If you have any questions we can help with, feel free to leave a comment or send us an email at hello@recurly.com

Recently, there’s been a high amount of email support requests. We spool mail locally from our web application to Postfix, then deliver it out to the internet. Well, it turns out that a large amount of that email was getting dropped. Watching the postfix mail logs was a bit disheartening after seeing numerous mail servers refuse to chat with our email server. We have SPF records setup, reverse DNS, and deliver mail from a dedicated IP address — it turns out that that’s still not enough.

To our customers: I’m sorry we didn’t figure this out earlier. We haven’t done a good job delivering our billing emails to your customers. Right now, we are evaluating multiple ways to improve the email delivery rates for the emails we send to your subscribers on your behalf. There should be an immediate uptick in the delivery rate for your emails today. And over the next couple weeks, we’ll determine the best way to reliably deliver your emails with the correct domain keys, SPF records, etc so that they work even better than if you were to send the emails yourself.

To other start-ups: I hope you read this and then realize that running your own SMTP server on dedicated, non cloud-based servers can still be problematic. I thought that because we’re not in the cloud, we don’t need someone else to handle our emails — looks like I was wrong. To remedy the situation, we’re now evaluating SendGrid (shout out to another CEO named Isaac). I’ve heard great things about their service and I’ve been comparing email headers all evening. It looks like their product is doing a fantastic job handling bounced emails, invalid email addresses, ISP feedback loops, domain keys (something we didn’t have setup), SPF, and everything else. Their web UI is a little rough around the edges, but so far it looks promising. Assuming their product lives up to its marketing material, it will help us dramatically improve our email reliability.

We’re not email experts and we don’t have time to build it out ourselves — (this sounds so familiar, right?).

Once again, a big thanks to everyone for being patient as we improve our email issues.

I’m happy to announce an open source Ruby on Rails client application available now up on github. The client application demonstrates the REST API calls you’ll use in order to get your rails application processing subscriptions and one time payments with Recurly.

The client application depends on Recurly’s Ruby client library, which is available as a Ruby gem (via gemcutter.org) or plugin.  Please see the Ruby client documentation for installation instructions.

If you run into any problems using the app, drop us a line over in our support forums.

Cheers,
-james

If your users forget about your service during the year and then they see the yearly renewal on their statement, they’re going to remember your service… and not in a good way. Worse yet, they might want their money back. That usually means they’ll ask you for a refund (and you should be willing to issue it if they really haven’t used the service) or they’ll attempt a charge-back (and that sucks for you and your bank account).

So right before the yearly subscription renews, remind your users two weeks ahead of time about the upcoming charge. This gives them plenty of time to opt-out of the subscription. It also gives you a chance to remind them of the value you provide so they will continue paying for the service. It’s just that easy to keep everyone happy and make more money.

And yes, Recurly will be adding this feature before your yearly subscriptions get close to expiration.

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

Our REST API is pretty easy to consume, yet without an open-source .NET client library to start with, we found that our clients’ integration times took an extra day of effort.  So we started our own.

This lightweight library uses fast-forward only XmlTextWriters and XmlTextReaders along with Stream readers and writers so you can be assured it’s fast.  It also works great in .NET 2.0 and above.  And finally, it is strongly typed and boasts a wide range of explicit exceptions to help you handle errors.  The library is about 85% completed today and will be finished very soon.

So if you’re looking for a simple to use, subscription billing service to power your ASP.Net websites, check out Recurly and our open-sourced C# library.

Thanks to everyone who submitted feedback during our private beta.  And if you didn’t make it into our private beta, thanks for waiting–we’re ready for you now.

Pricing

During our private beta, we heard from all of you about our pricing.  Our percentage pricing works great for companies with lots of small transactions.  However, several companies with larger subscriptions fees and fewer accounts expressed concerns about the predictability of Recurly’s pricing.  So today we’re adding a new pricing option based on the number of your active subscribers.  At the end of the month, Recurly will calculate the percentage fee and the flat fee based on the number of active subscribers — you will only be charged the best price.  There’s no need for you to decide which tier or pricing scheme to use.  Please see our updated pricing page for more information.

Remember, our pricing is based on the number of active subscribers — not the number of accounts.  We want to know about all of your users so we can provide statistics about your free vs paid accounts.  And by tracking your free users in Recurly, you can easily service their accounts from our interface.

International Payment Gateway Support

Recurly supports 11 payment gateways today, and that list continues to grow.  With our broad gateway supports, Recurly works with companies across the globe.  If you’re curious if we support your preferred gateway, please see our full list of supported payment gateways.

Check out the Open Beta

We invite you to learn more about Recurly and join the beta today!  We’re excited to see how you’ll use Recurly.

These updates make deploying subscription billing and interacting with your subscribers even easier. Our expanded international payment gateway support means even more choice and flexibility in the ways you transact your business.

Here are some of the top new items we’ve added:

• Enhanced UI look and feel
• Even greater International Payment Gateway Support
  - New gateways supported for US, UK, EU, Australia and Asia
• Improved Subscription Management Features
• Enhanced Subscriber Invoicing
• Streamlined Recurly signup process
• Additional subscriber retention features
  - Enhanced declined/cancelled card handling
  - Additional customizable and automated email options

All of these features are fully functional and live today in the beta. If you’re an international or US based company, there’s never been a better time to get started with Recurly. For access to our private-beta, email us at hello@recurly.com. Thanks and we look forward to helping you take the pain out of recurring billing!