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.

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

Setting up the integration is easy:

1. In your PlayNice.ly project, go to the ‘Project Settings’ page, select ‘BitBucket’, copy the BitBucket URL and hit ‘Save settings’.

2. Go to your BitBucket repository and load the admin page

3. Click on Services, and then add a POST service

4. Paste the URL in and click save settings

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.

Before we go on, I should mention UCC stands for ‘Unified Communications Certificate’. We will be using the phrase ‘UCC certificate’ quite a lot in this blog post. Yes, it is a bit redundant, but that is just how we roll.

Generating the private key & certificate signing request

This section is largely based upon HTTPS Virtual Hosts in Apache and Creating a Certificate With Multiple Hostnames.

What sets UCC certificates apart is their use of the subject alternative names (subjectAltNames). This is a list of host names for which the certificate will be considered valid.

To generate a certificate with subjectAltNames we need to change the openssl.conf slightly. On Ubuntu, this can be found at /etc/ssl/openssl.cnf.

1. Make sure the following setting can be found in the [req] section:

[req]
req_extensions = v3_req

2. Ensure the following section exists, and that it contains the given settings:

[v3_req]
subjectAltName = @alt_names

3. List the valid host names

Now list the host names for which your certificate should be valid in a section called [alt_names]. Note that the (monetary) cost of signing this certificate will increase with the number of hostnames you specify.

[alt_names]
DNS.1 = example.com
DNS.2 = hello.example.com
DNS.3 = testing.com
DNS.4 = www.testing.com
DNS.5 = foo.testing.com

4. Generate your private key

If you do not already have a private key, then generate one now:

openssl genrsa -des3 -out ssl.key 2048

This will put your private key into ssl.key in your current directory. Note that if you specify a passphrase for the private key, you will be required to enter it every time you start/restart/reload Nginx. This may be acceptable to you, but it means it will not be possible to start Nginx automatically on system startup or after a failure.

If you choose not to specify a passphrase, then just make doubly sure to store this file safely.

5. Generate your certificate signing request

Once you have your private key, you can use it to generate your certificate signing request:

openssl req -new -key ssl.key -out ssl.csr

You will be prompted to enter a number of values. Some of these may be used by your chosen SSL provider to verify your identity. The values will also be available to people who access your secured websites.

Once done, your certificate signing request will be located in ssl.csr in your current directory.

You can check that everything looks OK by running:

openssl req -text -noout -in ssl.csr

Choosing a UCC SSL provider

There are a number of UCC SSL providers out there, each with a range of prices. As this was our first experiment with UCC certificates we decided to use GoDaddy as they seemed to be the cheapest around and we felt that there was every chance that this wasn’t going to work!

Whomever you choose, they will probably ask you to upload your ssl.csr file (or just paste the contents into a textbox).

It took a couple of hours for GoDaddy to do all of its security checks. But when it was done we were able to download our fully functional UCC SSL certificate.

Now let’s setup Nginx…

Chained certificates (optional)

It is possible that your SSL provider will issue you with a chained certificate. The reason for this boils down to security.

If this is not the case for you then you can skip this section. We used GoDaddy, and they did issue a chained certificate.

For Nginx to handle this, we just need to combine our certificate and the chained certificate into the same file (Nginx docs on the subject). All you need to do is create a file in which your domain’s certificate appears first, followed by the chained certificate.

So, on the command line:

cp mydomain.com.crt mydomain.com.combined.crt
cat chain.crt >> mydomain.com.combined.crt

For GoDaddy, the chain.crt file is called gd_bundle.crt.

It is the mydomain.com.combined.crt file that Nginx will now need.

Once again, if you do not have a chained certificate then you can ignore this step.

Setting up Nginx

The first thing you need to do is add the following to the http block of your Nginx config:

ssl_certificate /etc/nginx/ssl/cert.pem;
ssl_certificate_key /etc/nginx/ssl/cert.key;

This ensures that the SSL certificates are available to all your Nginx server blocks. You can specify these settings on a per-server basis, but doing it this way saves a little memory.

From here, there are a couple of ways to setup Nginx, you can choose which is best depending on your situation.

The easy way

You can simply add a few extra options to an existing server block.

server {
	listen 80;
	listen 443;		# This is new
	ssl on;			# This is new
 
	server_name foo.testing.com
	root /home/foo
 
	...
}

And that should do it! Just restart Nginx.

The slightly less easy way

You can also create an entirely new server block to handle HTTPS requests, so you end up with two server blocks:

server {
	listen 80;
 
	server_name foo.testing.com
	root /home/foo
 
	...
}
server {
	listen 443;
	ssl on;
 
	server_name foo.testing.com
	root /home/foo
 
	...
}

This can be useful if you need to have slightly a different configuration for your SSL site.

Serving Django via FastCGI

If you are serving Django via FastCGI then you are going to need to pass through a HTTPS parameter to the FastCGI process (Django uses this information when generating URLs for HTTP redirects). This isn’t too hard if you use two separate server blocks:

server {
	listen 80;
 
	server_name foo.testing.com
	root /home/foo
 
	...
 
	location / {
		fastcgi_pass 127.0.0.1:1234;
		fastcgi_param PATH_INFO $fastcgi_script_name;
		fastcgi_param REQUEST_METHOD $request_method;
		fastcgi_param QUERY_STRING $query_string;
		fastcgi_param CONTENT_TYPE $content_type;
		fastcgi_param CONTENT_LENGTH $content_length;
		fastcgi_param HTTPS off;	# HTTPS set to off
		...
	}
}
server {
	listen 443;
	ssl on;
 
	server_name foo.testing.com
	root /home/foo
 
	...
 
	location / {
		fastcgi_pass 127.0.0.1:1234;
		fastcgi_param PATH_INFO $fastcgi_script_name;
		fastcgi_param REQUEST_METHOD $request_method;
		fastcgi_param QUERY_STRING $query_string;
		fastcgi_param CONTENT_TYPE $content_type;
		fastcgi_param CONTENT_LENGTH $content_length;
		fastcgi_param HTTPS on;		# HTTPS set to on
		...
	}
}

Notes on browser compatibility

This section has been added to the original post following the Hacker News discussion .

Some readers have made points on browser compatibility that I think are important to highlight here:

• It has been reported that some older Android devices have problems with UCC certificates, specifically those containing wildcard hostnames.
• The technique detailed here is different to that of SNI, which is not supported on Windows XP.
• As one reader pointed out, this technique is not well suited to domain lists which frequently change as registrars will probably charge for signing the updated certificate. SNI or Wildcard certificates may be more suitable here.

Please leave a comment if you have any points you would like to add to this list.

And that’s it!

You should now be able to point your browser to https://… and see your site being served securely.

Lastly, I should point out that every asset in the HTTPS version of your site will need to be addressed using an HTTPS URL, otherwise your visitors’ browsers are likely to complain.

Please let me know if you have any problems.

If you found this blog post useful then please checkout our bug tracking app, PlayNice.ly.

Update 1: There is an interesting discussion regarding browser support of this technique over at Hacker News. Please give us an up-vote if you are feeling kind

CodeProject

We have Pieter Noordhuis discussing what’s new in Redis 2.2 followed by Salvatore Sanfilippo talking about Redis Cluster and finally, the Q&A session that capped the night. Enjoy!

What’s new in Redis 2.2

Redis Cluster: The road ahead

Q&A

Do you have an idea for a future Redis meetup?

CodeProject

In addition to the usual refinements to speed and performance, we made a few bug fixes, overhauled the process by which you create new projects and released one major new feature: you can now import data from a GitHub or FogBugz project to PlayNice.ly. Woohoo!

We’ve overhauled the flow when creating a new project and made it easier to add people to a project with the introduction of the team-picker interface and auto-lookup of PlayNice.ly users. We also introduced an import feature to support those who wish to migrate from GitHub or FogBugz.

Simple, effective, awesome.

Adding people to a project

As you use PlayNice.ly, you develop a shared work history with your colleagues. We distil this information into a single view of ‘the usual suspects’. The people you work with most regularly appear at the top of the list. You can see the projects you’ve worked on together for context. You can also add people by their PlayNice.ly username, which is nice and fast thanks to some shiny new auto-complete action.

Easily add people to your projects

Importing data

You can now import a project from GitHub or Fogbugz into a new PlayNice.ly project. We’ll soon start working on import frameworks for other services – so if you have a particular request, please email support@playnice.ly and let us know.

Import project data from GitHub

Import from FogBugz

Other fixes and tweaks

Source code integration: We fixed a bug that resulted in commits from Subversion displaying multiple times in the Activity stream.

Describing and commenting on items: We improved our Textile parser to handle malformed tags more gracefully. This used to cause problems if you pasted exception errors in the description or comments field, but not any more.

Milestone behaviour: Fixed a bug where the Add Milestone button wouldn’t work if all the other milestones were archived.

Email notifications: Fixed an issue where you might have received an email notification of an item that you edited (which doesn’t usually happen).

Continuity error when logging out: If you logged out and then logged back in again, you would be redirected to the Activity page rather than the Playground. No more.

CSS glitch: You may have seen a CSS glitch that caused the UserVoice feedback dialogue to look very broken. This is now fixed.

Password reset: We fixed an issue with the password reset feature – you can now reset your password with ease.

Project settings bug: For a short while, you wouldn’t have been able to manage your email settings or remove someone from the Project Settings page. This is now fixed.

Playground interface weirdness: We fixed a seriously juicy bug which involved strange and unexpected behaviour between the Project Selector interface and the Add Milestone button.

That’s a wrap!

And that’s all for this week. If you have ideas, compliments or complaints, tell us at the PlayNice.ly UserVoice forum or email support@playnice.ly.

“So, what are you doing these days?”

“We’re working on a start-up!”

“Cool! What are you making?”

“A bug tracker!”

“ … Oh.”

Until they learned what we were doing differently, not many people could get themselves enthused about a bug tracking app, and honestly, I didn’t blame them. Most bug trackers are so sub-optimal that given the choice, many small teams opt to track their bugs in a Google Docs spreadsheet. Why? Because it’s lightweight, it’s web-based, it’s easily shared and it’s easy to use. Ultimately, of course, it’s still just a spreadsheet, so not massively suited to the pass-and-play style of collaborative software development. Which is why we scratched our own itch by starting PlayNice.ly.

We needed a bug tracker, so we tried out a few options and discovered that each one was more dismal than the last. We couldn’t find a single tool that was fast, fun, easy to use, and above all, fun. Did I mention fun? Bug tracking is a chore and any bug tracker that adds unnecessary layers of chores to the initial chore is, frankly, missing the point.

The bug tracker you use is important. It’s as important to your overall flow and happiness as a comfy work environment, a good supply of fresh air and sunshine and a steady stream of caffeinated beverines. This philosophy underpins everything we do in shaping PlayNice.ly and it’s the reason we keep the app focused on doing a few simple things incredibly well.

PlayNice.ly is entering what looks like a saturated market. The truth is the market is saturated - with bloated, sluggish bug trackers that do more to slow you down than speed you along. PlayNice.ly is here to change that. Start your 30-day free trial today and see the difference for yourself.