Testpad 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.
The Basic Components
Billing for a subscription service basically comes down to a make, buy or ‘assemble’ decision with four main components:
- Payment Gateway: the service that performs the actual billing of a customers credit card
- Merchant Account: an account into which credit card payments are initially deposited, and back out of which any chargebacks are taken; the merchant account is separate to the company’s bank account (which in turn can be referred to as the ‘settlement account’)
- Payment Method Details Collection: the service that collects and stores credit card details and uses them to initiate charges via the payment gateway. As this component handles and stores payment method details it must be PCI Compliant.
- Recurring Billing business logic: the code or service that handles subscriptions; the main task of which is to trigger the payment gateway to make charges every billing period. Usually also responsible for handling payment failures, reminder emails (called ‘dunning’), payment holidays, cancellations etc.
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!
What are your priorities really?
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
- minimise development time i.e. the amount of UI and code we would have to design, code, test and maintain,
- minimise upfront costs such as setup fees or fixed monthly subscriptions,
- and by implication: find an all-in-one solution to minimise the points of contact with 3rd-party providers and any integration hassles between different providers.
And non-goals included:
- not trying to minimise transaction fees; this will be an optimisation job in the future when there is revenue to optimise
- similarly, not trying to minimise foreign-exchange costs (Testpad is based in the UK)
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.
Comparison of Subscription Payment Providers
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.
Integration Checklist
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
Who is hosting the payment details pages? (aka PCI compliance)
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.
Free Trial
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.
Subscription Plan Design
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:
- are there limits or constraints associated with subscriptions (such as number of users, or other usage metric) that need enforcing in the code?
- is it even worth enforcing these limits to start with?
- what is the impact on the UI for subscriptions of different levels? e.g. do you hide unavailable options or show them but with an up-selling message when clicked?
- subscription period: annual pricing as well as or instead of monthly?
- special deals for charities, open-source projects, academic institutions?
- is the product purely subscription based, or are there add-ons outside of the recurring charges?
Chargebacks and Refund policy
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?
Upgrades and Downgrades
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?
Cancellation Process
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 Failure Process
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:
- the content of the emails that get sent to your customers
- the interval and how many emails go out
- how is a failure finally notified to you and the customer?
- during the process of chasing up a customer, does your UI look or do anything different?
- what does your product and the UI do on eventual expiration/cancellation?
Discounts, Coupons and Vouchers
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.
Consider:
- granting accounts for free
- indefinite % discounts
- N months free or discounted
- single- or multi- use coupons
- coupon/voucher codes with customisable text (do they have to be ‘ugly’ strings of random characters)
- how might affiliate deals work? both in tracking and the nature of the discount they might be able to offer
Migrating Beta Audience
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
- how will these customers be converted into free-trial or paid accounts?
- will these customers be given a discount?
- do they get different messages (in the UI or emails) to regular sign-ups?
Currencies
There are three places to consider currencies...
- the currency your customers are charged in
- the currency of your merchant account(s)
- the currency of your settlement account(s)
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.
Sales Tax / VAT
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.
API Integration (callbacks / notifications)
Before selecting a payment provider, it’s worth looking at (or asking your engineers to look at) how their integration APIs work. For example:
- how will your system be told about successful subscriptions, changes and cancellations?
- how are notifications secured?
- do you rely on receiving notifications or do you also poll subscription status on some pages?
- how will you test notifications? It’s easy during an initial test mode, but think ahead to when your product and payment solution are live, how then will any changes in code that handle notifications be tested?
And More...
If you’re still reading, here’s a list of further details you might want to check you’ve got covered:
- frequency of transferring funds from the merchant account to your settlement account
- analytics and tracking: can you add your Google Analytics and Adwords IDs to the right pages?
- support for other kinds of payment method, purchase orders, invoicing
- don’t forget to update Terms & Conditions and Privacy Policies
- payment provider Test Mode features e.g. simulating payment failure
- payment provider reporting (dashboards, statements, order lists, statistics etc)
- process for adding a new subscription plan (and testing it) once existing plans are live? e.g. store test modes
Conclusion
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!)
