Web apps, credit cards, merchant accounts and PayPal
Posted by adam
As fantastic as this is, it is also a complete headache.
PlayNice.ly went through this process last year and it is only just getting entirely sorted out. There are bank accounts, merchant accounts, payment gateways and recurring billing systems… and they all have to talk to each other!
Actually, this Futurama quote popped into my head on more than one occasion:
You can’t just waltz into the Central Bureaucracy. It’s a tangled web of red tape and regulations. I’ve never been, but a friend of mine went completely mad trying to find the washroom there. – Professor Farnsworth, Futurama
TL;DR
This is going to take you a few months to get set up, but the only task which will really consume your time is integrating the billing system into your app.
But why not use PayPal?
PayPal has the potential to simplify this whole process considerably. Our ‘old school’ route took us a few months, but I imagine a PayPal setup may take just a couple of weeks at most.
We didn’t go with PayPal for a few reasons, but really came down to the fact that we just didn’t trust them with our startup’s revenue stream.
Of course, if you just want to take the occasional payments from a few users then PayPal would be a pretty good option.
A view from 10,000ft
The components of a typical web app’s payment processing system are, in our experience, as follows:
- Your app
- A system for handling recurring billing
- A payment gateway
- A merchant account
- A bank account (i.e. your startup’s bank account)
You may find that a couple of these points merge together. For example, your bank may be able to provide both your merchant account and current account. You can also choose to implement a recurring billing system yourself, in which case 1 and 2 would merge.
So let’s walk through an example. This is what happens when you take out a PlayNice.ly subscription:
- PlayNice.ly asks you to choose a plan and then sends you off to our recurring billing system (we use Recurly).
- The recurring billing system collects and stores your card details, and asks the payment gateway to charge your card for the first month of your plan.
- The payment gateway performs a few security checks and then asks PlayNice.ly’s merchant account to take the money from your card.
- The merchant account takes the money from your card, holds onto it for a number of days (more on this later) and then pays it into PlayNice.ly’s current account.
Every month thereafter, the recurring billing system will tell the payment gateway to bill you again, triggering step 3, then step 4.
Oh yeah, just like that
Needless to say, this is not trivial or fast to setup. It took us about 3 months and a few hundred pounds (GBP) in setup/subscription fees to get everything working (more detail below).
The silver lining is that it doesn’t consume much of your time. In total we spent a couple of hours on the phone (or emailing) each week during this period. Updating the PlayNice.ly app with concepts of trials & subscriptions was by far our biggest time-sink, but that is a whole other blog post.
Choosing your tools
Before you start signing up for anything it is a very good idea to first figure out the combination of tools that will work together. Your chosen recurring billing system needs to be able to talk to your chosen payment gateway, and your payment gateway needs to be able to talk to your chosen merchant account provider, and so on.
In addition to finding tools that will play nicely with each other, you should consider:
- Do you need to charge any taxes? For example, PlayNice.ly is based in the EU, so we need to charge VAT to our EU customers. We therefore chose Recurly to handle our recurring billing as they handled this for us. If you don’t need VAT support, Chargify is a very attractive option.
- The documentation quality for the APIs you will be integrating with.
- The quality of the API client you will be using.
- Do you need to bill in multiple currencies?
- The associated setup and ongoing costs.
Gotchas: Merchant account & Payment Gateway
Here are a few notes and gotchas that we learnt along the way:
- A customer can reverse a credit card charge, known as a ‘chargeback’. If they do, you have to pay that money back to the bank that provides your merchant account. (This doesn’t apply to debit cards, but our merchant account provider didn’t seem to want to think about debit cards too much.)
- Because of the above point, initially the bank will want to hold on to incoming payments for as long as possible, just in case it needs to issue refunds to your customers (as the bank doesn’t trust you to cough up any refunds yourself). For us, this wait time is about a month (!), but this can come down to 3-4 days over time.
- Your website will need to conform to certain regulations which your merchant account provider will specify. For example, we needed to have privacy/refund policies on our site, and clear contact information displayed. (But interestingly enough, our merchant account was provisioned before we made these changes live. Go figure.)
- Your payment gateway and merchant account will probably need to be setup to allow something called ‘continuous authority’. This allows your recurring billing system to have the authority to take subsequent payments from the customers card without having their card’s CV2 number present (no one is allowed to store the CV2 number, as it acts as proof that the customer is actually present). There may be an extra per-transaction charge for this.
- Accepting American Express payments is more complex as they effectively have their own merchant account which needs to be setup separately with your payment gateway. Ask your payment gateway and merchant account provider about this.
Gotchas: Recurring billing
We found the recurring billing setup pretty straightforward. The task that really ate up our time was making PlayNice.ly billing-aware (as we were previously in a free public beta phase). Even though we outsourced the recurring billing to Recurly, there was still a lot of effort involved in handling trial accounts, expired accounts, billing callbacks, account upgrades, account downgrades, copy writing, billing notification emails, pricing plans etc.
Do not underestimate this.
How much does it cost?
Every step along the payment processing path will probably have some fees associated with it. This is roughly what we were initially paying:
- Recurring billing system: $29/month
- Payment gateway: £20/month (about $33/month)
- Merchant account:
- Setup: £150 (about $244)
- About 2-2.5% per transaction + 0.85% per transaction for continuous authority
Our timeline
So how long did it take to get all of this setup? Longer than setting up a PayPal account, that’s for sure…
- Late August – Met with bank for current account setup
- Mid September – Current account opened (so this took about 3 weeks, which is longer than usual)
- Late September – Merchant account setup
- Mid October – Recurly setup & setup of test account with our chosen payment gateway
- Mid October – Early December – Getting everything to work together. This involved phone calls and support emails to find the correct settings for various interfaces, and finding that we needed to sign yet more forms that people had forgotten to mention. Boo.
- Early 2011 – Writing integration scripts to hook up Recurly to our accounting system (Xero, which we highly recommend).
All-in-all, it was about three-and-a-bit months before we could accept card payments. None of it was too time consuming, it just took a long time. We could have probably shaved a few weeks off this process if we were really in a hurry, but I really wouldn’t want to do this in a rush 
Big fat disclaimer
In case there is any doubt, I want to make it clear that this blog post represents our best understanding of how the system works. While I believe it to be accurate, it is quite possible that some statements are entirely wrong, untrue, fallacious or misleading. If so, I sincerely apologise and will only be too happy to make corrections. Please do not rely on this information without double-checking first.
