Update: Part 2 available
This is the first post of a short series about our experience of integrating payments into PullReview. My objective is to be as practical as possible. There will be code, but also some reflexion/question that are not strictly technical.
Why a short series? Because the material to cover is quite large for a single post, and I’ve discovered shorter pieces are both easier to write and more agreeable to read, so hopefully we both win here.
While this series is of course linked to our technical environment (Ruby on Rails) and provider pick (Stripe), it should be useful to most shops regardless of the exact technology and provider used – most of those problems will arise whatever the technology and payment solution.
Being the first post, it is more about starting up – notably picking a payment provider.
Billing is an epic, not a story
We’re a small shop, we see ourself as nimble, our sprints are one week long, and I like to say that most features are not extending the sprint duration. Yet the billing “feature” proved itself to be a complex one, which means you should try to divide it as much as you can (we did not/not enough, and it did bites us). The various posts are one way (among a lots of other) to split the work.
While fully integrating billing features into the application is not trivial technically speaking, don’t underestimate the business complexity. There are a lot of “small things that matters” to be decided – except of course if you already have your full payment/billing workflow thought out end to end, but that was not our case.
Gateways, payment providers and… Europe
We’re an European (Belgian) shop, and the situation about online payment in Europe is still lagging behind the one in the US. This means initially less choices. When we started looking for payment, Stripe was still present only in the UK, and the similar offers were few and far between. The environment is moving quickly (Stripe coming to Europe, PayPal acquiring BrainTree), so be sure to look by yourself before starting.
The “traditional” way of enabling payment was to integrate with Ogone, a Belgian based gateway. Tales from the trenches were rather bloody, as the integration had to be done on a quite low level.
Pick a product
I recommend you to take a look at the “full solutions” and pick one. Beside Stripe (which is probably the best known), you’ll find companies like BrainTree or PayMill. You’ll be in good company in any of them (BrainTree is used by GitHub & AirBnB, PayMill has build a nice list of customers in Europe, Stripe has numerous big names also like 4square or Rackspace).
Those kind of solutions are PCI compliant (which is something you want and don’t want to do yourself) and does not require any kind of merchant account.
We also are used to pick solutions quickly (the cost of the research may quickly invalidate any advantage of picking the “best” solution). We picked up Stripe when I received a beta invite the day we had to pick products. Our expectation was that it was used by a lot of people, and so probably quite mature and adequate to our (standard) needs.
If you are also using Ruby on Rails, I recommend buying and reading the Modern Payment with Stripe ebook from Peter Keen.
What you need (admin side)
In order to explain my “pick a full stack solution” argument, the setup on Stripe was limited to fill in basic information about our business:
Add a bank account (of course) and some account holders and you are good to go. Stripe is doing some background checks (legally required), but those were done in a couple of days and not blocking anything.
Even better: as Stripe will initially setup your account in “test”, even those information are not required. Stripe “test” environment allows you to do anything you want – except charging real money.
That’s good, as we want to do some tests first.
Stripe has a lots of options, and the road to billing is long, but a single step can actually allows you to do the single thing you need: charge a customer. That will be for the part 2 – “the only part you need”.