An overview (from 2011) of payment solutions available for subscription-based SaaS products. Drawing from Testpad's experience with FastSpring's all-in-one solution, delve into key considerations like selecting payment gateways, designing subscription plans, handling chargebacks, and managing currencies.
estpad recently integrated a billing solution for its subscription plans. With so many Software-as-a-Service products popping up I imagined there would be lots of off-the-shelf options to choose from and it would simply be a matter of fitting our requirements to features offered.
Well, yes and no.
Yes, there are lots of subscription-specific payment providers, but no, integration is not a simple matter. Providers vary in the way they bundle the component elements to take subscripton payments and this has big implications for the design and development effort. Even with a decent all-in-one provider, don’t underestimate the amount of additional work required designing and integrating how the subscription plans will work.
This article is based on Testpad’s experience from integrating FastSpring’s all-in-one solution for our SaaS-based software testing tool. I’m not a payments expert by any means, but hopefully these notes will prove useful to the next guy setting out on this journey.
Billing for a subscription service basically comes down to a make, buy or ‘assemble’ decision with four main components:
With the payment gateway and the merchant account you’ve got little choice but to buy. You don’t necessarily have to buy these separately though as some billing solutions bundle them into a single product. Whether these are bundled or not can make a significant difference to your setup and running costs.
However, payment details collection and recurring billing logic is very much a make or buy decision. Read on for the issues!
Now, before looking at potential payment providers and browsing my list of issues, it’s worth taking a moment to identify what your priorities are. With multiple decisions to make at each turn, knowing what your real goals are will save you time.
For Testpad, our goals had a flavour of Eric Ries’s MVP - Minimum Viable Product Payments. Actually, you could get even more minimal than what Testpad started with and elect to manually bill your first customers until you don’t have time to.
Nevertheless, Testpad’s goals in providing an automated billing solution were to
And non-goals included:
Plus, you might have several further, more detailed, requirements that you would like from your billing solution. For Testpad, whilst we had some in mind (like being able to gift customers a free month if we messed up somehow!), they took a back seat compared to the main goal of minimising dev time.
There are several companies selling subscription payment solutions. The following are the services that I checked out, offering various combinations of the basic components. All have great reputation at the time of writing. Whilst they also compete on many detailed features, I’m comparing them based on which of the the main building blocks they provide, as for Testpad, these dominated our decision.
|Hosted Payment-Details Collection
|Available in UK
|you host, lightweight PCI compliance
|you host, lightweight PCI compliance
|needs a US-based credit card
|you host, lightweight PCI compliance
|depends on plan
|PayPal Business Web Payments Pro
So. Enough with the basic scene setting. Here comes the detail. All of which is worth considering as it could influence who you partner with and what does or doesn’t get implemented in version 1.0.
In the spirit of Testpad’s testing service, a ‘design test’ for the following list can be found in the example library here: Online Payments Integration Checklist
You will need to be certified as PCI Compliant if your servers receive or store any payment card details. My take on this is that it is generally considered a pain to be avoided.
The obvious way to avoid the compliance process is to not host your own payment processing pages and let your payment provider handle it. Of course, this then means you’re not in direct control of these pages and are reliant on your payment provider for how much customisation is possible.
There are half-way houses too. Most of the providers listed let you host the payment forms, but have them POST their data directly to them and not via your servers, thus avoiding most, if not all, of the process of PCI compliance. With this approach, don’t forget to factor in time to design these pages (and all the other pages that go along with them such as error handling).
With the big impact this makes on how you host these pages, and what it means for the continuity of your branding, it’s worth considering this issue carefully for each of your shortlisted payment providers.
Are you thinking of providing a free trial? How is that going to work – is it free for a limited time, or is it free for a limited feature set?
A big decision is whether to take credit card details at the beginning during initial sign-up, or to require minimal details for the free trial and then look to convert people during the trial. This is probably best answered (in the longer term) with your own split testing. For Testpad, we went with keeping initial sign-up as simple as possible to maximise the audience giving it a try; confident that it will ‘trial well’ and be an easy buy decision later.
Some payment providers support a free first month, but can’t not take credit card details up front. If that’s the case, then you can still do a credit card-less free trial, but you will have to implement that part of the ‘plan’ manually.
Either way, if you’re deferring taking credit card details, don’t forget to design the UI flow and email nudges that encourage conversion during the free trial.
You probably already know what different subscription options (plans) you want to offer and how they will be priced. If not, that’s something best decided before you continue as it will have a fairly big impact on the payment integration design!
However, don’t forget to consider:
Chargebacks are when a customer contacts their card-issuer (e.g. their bank) to query a payment and request a refund. The card-issuer can then forcibly take the payment back out of your merchant account. These can be contested by the various parties involved, and this is a service that some gateways (or integrated payment providers) offer.
If you think your product might have a tendency to incur lots of chargebacks, it’s worth looking into the processes and costs in some detail. On the other hand, if your customer base is less likely to initiate chargebacks, e.g. because you’re selling to businesses and offer a transparent cancellation policy then it’s only worth simply understanding the issue and fees, and not worrying about whether it seems expensive or not (yet!).
Separately to chargebacks, there is also the issue of refunds, where your customers ask you for a refund. All the payment providers have a method for giving a refund, but vary in their fees.
Also consider how cancellations work. Should your customers get a refund for unused days/months of the billing period they cancel within?
If you’re planning to allow customers to upgrade or downgrade their subscription, if that’s even relevant to your product, then consider how that will actually work with respect to the billing cycle. It’s worth checking how your shortlisted payment providers deal with upgrades and downgrades.
Monthly subscription changes are typically simply changing the amount billed on the next cycle, with the new limits/features taking effect immediately. However, annual subscription changes might be more tricky. For Testpad, we just offered what the payment provider offered: the existing annual subscription is cancelled and refunded for unused months, and a new annual subscription is started (and billed) on the day of the upgrade/downgrade.
What UI features will you need to design to handle upgrades/downgrades?
How do customers cancel their subscription?
How is the cancellation actually implemented? Don’t forget you will need to effect cancellation both in your own code and with your payment provider so the customer doesn’t get billed again. It would be a disaster if you managed to cancel the account ‘locally’ but left the subscription running somehow with your payment provider.
Does cancellation happen immediately, or does the subscription continue until the next billing date? i.e. when you’re not offering partial refunds, the customer still gets what they paid for.
Do you delete cancelled account data or keep it dormant for reactivation in the future?
Can you prompt to get feedback at the point of cancellation? ‘Exit feedback’ can be very revealing and helpful in improving retention.
Payment failures are very common with credit card subscription payments (expiry, new cards issued, maxed out etc) and customers will need politely chasing up and reminding to enter their new details.
All of the main subscription-centric payment providers cover this, and in my opinion, is a big reason to use a payment provider in the first place - let someone else be good at the code that gets this right!
However, do consider what flexibility you have in terms of:
There are many reasons you might want to offer discounts, and the payment providers vary in the models for implementing them, so it’s worth considering what kinds of discount you want to be able to offer and see how they might be achieved with your shortlisted providers.
Many services are available as a (free) beta and sign up a significant audience before launching and starting the paid subscription plans.
If you’ve got a beta audience, consider
There are three places to consider currencies...
To keep it simple at the outset, you can just do everything in US dollars. However, you’re likely (but worth split testing!) to see higher conversion rates if you offer prices and charge in local currencies.
Then you’ll need to consider how the price is set in different currencies, as you probably don’t want to list $99 as £63.61; and this might need configuring on both your system (for the pricing plans page) and in the product definitions held by the payment provider.
Aside from the currency choice, Payment Gateways vary in which countries they support in the first place, so definitely check your payment provider/gateway can charge in all the countries you would like to sell to.
Depending on your location and the location of your customer, there may be sales tax (or VAT) to account for both in your records and on invoice/receipts sent out to customers.
You might also have preferences for whether your prices are displayed inclusive or exclusive of these taxes.
This is definitely something to checkout with your shortlisted payment providers as their support varies from no help to completely handling it.
Testpad went with FastSpring who completely handle this, so we didn’t need to dig into the implementation details any further.
Before selecting a payment provider, it’s worth looking at (or asking your engineers to look at) how their integration APIs work. For example:
If you’re still reading, here’s a list of further details you might want to check you’ve got covered:
Well, there isn’t really a conclusion as everyone’s requirements will be different.
For Testpad, based in the UK, it was an easy decision to go with FastSpring’s SaaSy service. It is an all-in-one package with a web-GUI to configure products and manage the account; no merchant account setup, no gateway setup, just one company to integrate with.
Had we been based in the US, it would have been a harder decision between Braintree, Stripe and FastSpring as all-in-one offerings. Nevertheless, FastSpring have awesome feedback for their customer service, and deservedly so from my own experience.
If any of this has been helpful, please get in touch. Follow Testpad on twitter: @testpadapp.
And do checkout Testpad if you want a refreshingly simple tool to improve your testing (or if you want to see how well we integrated FastSpring!)