Building a subscription website as a small business owner
If you're a small business owner looking for a subscription website builder you've come to the right place. This builder allows you to focus on your business whilst the subscription website assists you with all the technical matters. It allows you to simply manage:
- The items you sell
- The amount you charge for each of them
- Your customer subscriptions
- and whether you charge up front, monthly, or both
Understanding Payment Gateways & methods
If you're a subscription website, you need to think hard about taking payment. The UK has many schemes which may help, or bring more risk to you taking recurring payment. We cover the two main options:
- Direct Debit (GoCardless, SlimPay, SmartDebit)
- Online Credit Card Transactions (Stripe, Realex Payments, Paypal)
Using Direct Debit for Subscription Websites
Direct Debit has a long history (watch the video) in the UK. It is a very convenient way to take varying payments without having to re-authorise bank details with your customer every time. You must understand your obligations, however, for example, the customer's instant right to get their money back without question. If you're likely to process a lot of refunds, direct debit is not not the right payment method for you. On the other hand, if you're customers are loyal, and your service owes itself to varying charges (e.g. charge by usage, amount of etc) then direct debit is perfect because you can alter the amount of money you request from your customers easily & automatically. For this reason, we've built this method in as the prefered method for UK subscription website builders at our subscription site builder.
How Direct Debit Began in the UK
Key points from the video for how Direct Debit might be a good option for your subscription website:
- Collect money directly from the person who owes you money**
- Easier to charge variable amounts of money, at variable times
- It's better than a standing order, because they're for fixed amounts & require more action on the customers part
- Authority given to the creditor is high (you the seller have a lot of power...to take variable amounts, but also a lot of responsibility!)
- Since 1964, well understood in the UK for your customers
Inspiration station! Did you know? Direct Debit came out of "The requirements of Unilever to collect money from thousands of small retailers selling ice cream!" - Alastair Hanton (Inventor of Direct Debit)
Could this growing small retailer be your subscription website?
** Note that services like GoCardless are middle-people in the sense that by using them you actually don't have a direct ability to take money in that sense. In practice, it makes little difference other than making it slower and more expensive for small businesses. This is legislative/policy pain: I've spoken to banks like RBS who will not offer direct debits to small businesses without significant turnovers. It's a matter of balancing the risk for the banks/consumer but smells anti-innovation to me when compared to payment systems in other countries.
Using Card payments like Stripe & Paypal
Paypal: To take recurring payments through PayPal, you have to become a PayPal Payments Pro member first costing £20 per month. On top of this, PayPal charge an additional £10 per month to begin taking recurring payments. Both credit and debit cards work, with recurring payments through PayPal not requiring a direct debit to be set up via your bank, PayPal handle and collect all of the payments on their servers, however, this payment does come out as a direct debit.
Stripe: Taking recurring payments through Stripe can be done directly through their website. Stripe creates an invoice that allows for one-off charges to be factored in. Stripes API sets up a direct debit for both credit and debit cards, again this can all be set up through Stripe. Stripe does not charge an extra fee for this function, however, like most payment gateways, they do charge some fees. We have compared the prices of payment gateways in this blog, so you don't have too.
Taking card payments compared to direct debit
Bear in mind taking card payments more often than not goes through the card payment system (usually the visa network). A traditional card payment is less reliable than the direct debit mandate for the following reasons:
Card data can expire and be revoked
Flexibility and control
Card Data can expire
Whilst you're off and not storing card data yourself directly (and that's arguably a good thing for security) card data expires and must be renewed. If left to expire your transactions will no longer work, this requires customer intervention to provide the latest information and therefore is a barrier to your subscription website. If you're building a subscription website which needs to put automation at the forefront of success, think about how you can minimise the amount of customer intervention needed to build a seamless subscription website experience.
Direct debit mandate avoid this risk because payment information is tied directly to the bank account and not to the card. This means payments from your subscribers succeed where expired card information would have caused your transactions to fail. If your subscription website is looking for long-term subscriptions from your customers, consider the impact of taking card payments vs setting up direct. You might find that building a recurring payment website on top of direct debits is a better fit. Take into account, however, the difficulty in handling refunds on direct debit systems through GoCardless which is currently a very manual process. Subscription Website Builder is working on abstracting this process to make it automated. You also need to be clear about your responsibilities and consumer rights with regards to direct debit, a customer can request the money back right away under the direct debit scheme. You need to make sure you have adequate protections for yourself when you're building a subscription website.
Flexibility and control
Due to the nature of direct debits, you're free to vary the amount of the payment. Generally with card payment systems like Stripe and PayPal, you may need to renew this card information (for example when it expires) and generally card payments are not suitable for variable payments at all; this is why PayPal actually sets up a direct debit in the background (except the direct debit is not assigned to your bank account, it's to PayPal's). Then finally from PayPal, you're able to request that money into your own bank account.
Building a subscription website as a developer
As a developer you know you always have to strike a balance between giving your clients direct control over their website compared to a complete Web Server Gateway Interface (WSGI) experience. Subscription-based websites however things get a little bit different. You have to:
- Decide on the relevant payment gateways
- Hook up all the different endpoints
- Write all of the custom subscription logic
- Usually with less time than you have
Subscription website builder has done a lot of the hard work for you. It allows you to build a subscription website within minutes, and enough to allow you to style the website for your client quickly. Read the docs here.
Getting started fast and helping your clients sell their products quick is the fastest way to learn. This is borrowing ideas from the various agile approaches, the moment code goes to production the moment you start to really learn. There's little point investing hundreds of hours in building a subscription website only to find a fundamental requirement is missing. Lethal subscription website builder package as a prototyping tool to trash out your ideas and create a minimal viable product - whilst at the same time keeping your client happy with something which works from week one.
Abstracting away payment gateways for subscription websites
When you're building a subscription website for a small business, there's often very little new about the business operationally. There is a lot of repetition in process between clients & projects.
- Form validation
- User flow
- Order management
Omnipay in the PHP world is a beautiful example of the DRY principle. It presents an interface above many different payment providers. The result? You save time, you don't have to learn a new API for each payment provider! The same is true for most websites, especially true when you're building a subscription-based website. Essentially it boils down to three things:
- Present the various options to the user (usually three)
- Wait for them to eventually choose the middle package
- Get them to the "thank you page" as quickly & ethically as possible
That's ultimately what the subscription website builder is for, yes the code quality is a bit like this:
But that will improve over time, its functional and that's what matters apparently.