PlayNicely - Beautiful collaboration for software developers

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:

1. Your app
2. A system for handling recurring billing
3. A payment gateway
4. A merchant account
5. 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:

1. PlayNice.ly asks you to choose a plan and then sends you off to our recurring billing system (we use Recurly).
2. 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.
3. The payment gateway performs a few security checks and then asks PlayNice.ly’s merchant account to take the money from your card.
4. 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.

Sometimes it is really nice to keep everything in one place. User feedback, for example, is a good example of this. Does your project really need its own feedback app such as UserVoice, or can you use the tools you already have?

This is the quandary that Riley Dutton faced while working on his latest project. His solution was to create Waterslide, a feedback widget that pushes data directly into PlayNice.ly (using our API).

It is still early days for this widget, but it is going to be great to see how Waterslide develops in the coming months!

I gave a quick talk at the Hacker News London meetup last night on some lessons that PlayNice.ly have learnt over the last year or so. If you’re thinking of doing a startup then please check out these slides!

Let me know if you have any questions or feedback!

Good news everybody, release ‘Hermes’ is now out! From today you can unlock extra projects on your paid PlayNice.ly plan using the new Love PlayNice.ly page.

All you need to do is recommend PlayNice.ly to your friends. When your friend signs up, you will both receive an extra project. So go to the Love PlayNice.ly page and get your free projects!

Even more new features

In addition to all the love:

• We now have experimental JSONP support in our API. See our JSONP documentation page for details.
• Unfuddle import: you can now import Unfuddle tickets when creating a new project.

Today we are very pleased to announce the PlayNice.ly API, currently in beta. Woo hoo!

You can find the gory details at: http://docs.playnice.ly/api/

Why is this good news? You can now get fast and easy access to all your projects, milestones, tasks and comments in a common format. This gives you much greater control over your data plus the ability to integrate your own tools with PlayNice.ly.

Lots of you have been asking for an API so we’re really glad to finally deliver one, and we’re looking forward to seeing how everyone uses it.

You can expect to see these new features coming to the API in the near future:

• JSONP support
• More API calls
• OAuth 2.0 support

In the mean-time, let us know if you have any ideas, suggestions or problems. We always love to get feedback
CodeProject

1. Use one IP address per SSL-enabled site – clearly not a great solution considering the increasing scarcity of IP addresses. Also, some cloud providers (e.g. Amazon EC2) only issue one IP address per server.
2. Use a wildcard certificate – This can work well if you only need to secure sub-domains. The cost can also be considerably greater for this type of certificate.

But it is now also possible to use a Multi-domain UCC SSL certificate. This allows you to have a single certificate which covers up to 150 domains. The documentation for technique is still a little thin, so we wanted to share our process for getting this set up.
Continue reading →