The secret is out – WooCommerce is a great way to create an online store. It offers generous built-in functionality in the free plugin. There’s a range of free and commercial themes, payment gateway and shipping integrations, abundant hosting options, and an ecosystem of skilled developers.

This all makes it possible to create almost any type of online store with WooCommerce.

But not all eCommerce uses online shopfronts. How does WooCommerce fare for other eCommerce applications?

Software as a service (SaaS) is one important and growing category of eCommerce. There are many popular and established vendors for SaaS billing solutions, like Recurly, as well as open source frameworks, like Spark for Laravel.

But what about WooCommerce?

Is WooCommerce as Suitable for SaaS Billing as It Is an Online Store?

SaaS has no need for some of WooCommerce’s features, like its shipping function or product catalogue. Many of its themes focus on product photography, with look-books and image galleries. The broad range of shipping integrations doesn’t matter, nor does the cart process.

So a lot of WooCommerce’s benefits have no use with SaaS. But that doesn’t mean it’s not suitable.

The base requirements for most SaaS billing systems are:

• A pricing table
• Recurring billing
• Simple sign-up flow with coupon and tax support
• Event notification system to connect with you SaaS, like webhooks

WooCommerce offers all these, and much more.

This post will look at how we set up and use WooCommerce for SaaS billing at Robot Ninja. In the process, I’ll also give my view on whether WooCommerce is a good fit for SaaS.

Step 0: Two Decisions for SaaS Billing

When pricing Robot Ninja, there were two main decisions we had to make:

• What pricing model should we use?
• How should we put in place that pricing model?

The first of those was a tougher decision than the second.

We were confident we could implement almost any pricing model we chose with WooCommerce. At least that was the assumption we started out with.

Choosing a model was the hard part.

Choosing a SaaS Pricing Model

There are many options for charging for SaaS.

Here are some of the pricing parameters across various SaaS pricing models:

• Billing unit: What is the atomic unit for your service? Is it a user account, page view, gigabyte of storage, CPU cycle, or some combination of things?
• Sign-up fee vs free trial: Some SaaS has an initial cost, like the provision of a physical device. Others have no such cost, allowing vendors can make it more attractive to sign up by offering a free trial.
• Prorated vs flat price: A customer only uses your service 7 days out of a month. Do you still need to charge them for the entire month? Or do you charge only for the days of usage? This can depend on whether the cost of using the service differs to the cost of providing the service. For example, the cost of an email sending service varies on the number of emails sent. The cost of providing a physical web server for a period of time requires the cost of hardware regardless of usage.
• Pre-paid vs. post-paid: Should you charge for your service in advance of the customer’s use of it? e.g. $10 on the 1st of that month’s access. Or should you charge for the service after the service period? e.g. $10 on the last day of the month for that month’s usage. The choice here depends on a few things: the cost of provisioning the service; the likelihood of customers defaulting on payments; the complexity of proration. It’s easier to charge for prorated usage than to manage credit for prepaid services.
• Cancellation credit: What happens if a customer cancels the service during the billing cycle? If they pre-paid for that period of service, are they credited for the unused amount? And what happens if a customer cancels only one unit of the service but keeps the others active?
• Billing cycle: Will your customers be able to pay monthly, yearly or both? Will you provide a discount if they pay yearly instead of monthly?

I’ll stop there. But I could go on. With those 6 parameters alone, it’s possible to come up with hundreds of different pricing models. That proves my point – SaaS pricing is complex and multifaceted.

Pricing Robot Ninja

The decision process we went through for each of these parameters is beyond the scope of this post. In short, we wanted the most generous and fair pricing model possible. Mostly to make the service accessible to all store owners and help us achieve our company’s 3 year goal.

Slack’s Fair Pricing Model

While deciding on our pricing model, we reviewed the models of many other companies. Especially those of services we use at Prospress. One stood out from the crowd – Slack.

Slack takes the complexity of their billing a little beyond that of other vendors. But in doing so, they were able to create the most fair pricing of all the services we evaluated.

In Slack’s words:

We believe you should only have to pay for members that are actively using Slack, so we offer a Fair Billing policy.

The short version:

• You’ll only be charged for members that are active on the day that you upgrade to a paid plan.
• If all members become inactive, you will be charged for a minimum of one member, unless you decide to downgrade to the Free plan.
• Any changes to the number of active members will be reflected in your monthly statement.

In the sincerest form of flattery, we copied their model. The major difference – we decided to use post-paid billing, not pre-paid. This saves us using credits to account for proration. We instead bill for usage at the end of the monthly cycle.

This adds more risk on our end because we pay for resources used to run the tests that we may not get back if we are unable to collect payment. For now, though, that risk is worth the reduced overhead in managing our billing.

The other difference – we don’t charge per user. For Robot Ninja, it makes sense to charge per store. The main cost of running the service is testing a store, not the number of people with access to run or review tests. The main benefit is being able to test different stores, not have more people run tests on the same stores.

In short, the pricing model we chose for Robot Ninja:

$79 per active store per month. We charge only for days where a store is active.

When upgrading your account from free to standard we’ll make a one-time charge to your credit card for $79. This covers the cost of provisioning a debit card for live payments.

For each store on your account, we track how many days it is active each month. We then calculate a prorated total for that store based on daily rate. We then charge that for the previous month.

If the total for all the stores on your account does not reach $79 for the month, we bill a $79 minimum instead.

Sound complicated? Definitely. We opted for fairness over simplicity. It’s too soon to say whether this is the right choice from a customer perspective. We don’t want to confuse our customers! But we hope the benefits of the pricing model outweigh its complexity.

Something of note: We were able to freely choose such a complex pricing structure only because we knew we could achieve almost anything with WooCommerce.

WooCommerce for SaaS Billing

As the developers of WooCommerce Subscriptions, naturally we planned to use it for recurring billing.

One problem…

Out of the box, Subscriptions charges a non-prorated, up front price for a predefined billing cycle. For example, for a $10 / month product, it will charge $10 at the start of the next monthly cycle. That’s it. Simple billing. Completely different to our chosen pricing model.

So why were we confident we could use a post-paid, prorated pricing model with WooCommerce and Subscriptions? The APIs!

WooCommerce provides powerful objects, like `WC_Order` that make advanced recurring billing simpler. Especially when combined with APIs in Subscriptions for creating orders and processing payments.

As WooCommerce is self-hosted, we also knew we’d get complete access to all our data to use as needed. From order totals to payment tokens, it’s all available in our database. We weren’t limited to only data that public APIs exposed.

So how did we go about implementing our pricing model?

Introducing the Subscription Resource

Before writing any code, we took a step back and wrote a brief specification to abstract our pricing model.

We knew our friends at SkyVerge were working on a Memberships for Teams extension that offered “per seat” pricing for Memberships. This has similarities with SaaS pricing models. So we wanted to see if we could come up with something that could serve both use cases.

What we came up with was a generic “resource.” A resource that links a line item on a subscription to some external thing. On Robot Ninja, a resource is a store. Other resources might be a a video for an education site or a server for a web host.

Resources can be pre-paid or post-paid. They can be prorated daily or charged in full. They can use any billing schedule Subscriptions supports. As well as a free-trial or sign-up fee.

To implement this logic for a ”resource,” we developed the WooCommerce Subscriptions Resource library. We’ve since publicly released it.

The WooCommerce Subscriptions Resource Library

The code in the Resource library handles creating and linking a resource to a subscription. To use it, 3rd party code needs to tell it:

• to create a resource, and
• whether the resource is pre-paid or not,
• whether to prorate the resource or not,
• the ID of the external object (e.g. store ID in Robot Ninjas case, but it could be a membership ID or any other object’s ID),
• the ID of the WooCommerce subscription object to link it to,
• the resource’s status at the time of creation,
• when the resource is activated (if it wasn’t active when it was first created),
• when the resource is deactivated.

To do this requires just a few hooks, as outlined in the library’s Usage guide. The Resource library takes care of everything else.

Thanks to the APIs and core objects WooCommerce and Subscriptions provide, we were able to implement the billing with less than 1,000 lines of code and about 2 days of development time.

Once the Resource library was complete, we triggered a few hooks and voila – Slack-like billing for Robot Ninja.

WooCommerce for SaaS Sign-Ups

Now we had a pricing model and that model was working with WooCommerce. The final piece of the puzzle was streamlining the sign-up process.

We didn’t want the product page or cart page. We wanted a single, simple page for customers to be able to enter the required information to sign up for a subscription.

We were able to cheat here a little. We already knew of a handy plugin to create a single page checkout flow. We installed it. Set up a One Page Checkout page, linked to it from our pricing page, and had the simple sign up process we needed.

Other Configuration Needed to Use WooCommerce for SaaS

As a SaaS is not a store, there were some other things we didn’t need on Robot Ninja. These were configurable with WooCommerce’s built-in settings:

• Shipping: WooCommerce lets you disable this store wide feature out-of-the-box. Go to the WooCommerce > Settings > General administration screen. Select Disable shipping & shipping calculations for the Shipping Calculation(s).
• Inventory: Most SaaS products have no inventory, and Robot Ninja is no exception. WooCommerce makes it easy to disable inventory. Go to the WooCommerce > Settings > Products > Inventory screen. Uncheck the Manage stock setting.
• Guest Checkout: Customers need an account to use our service, as they will for most SaaS. That means we can disable the ability for guests / non-registered users to checkout. To do this, we went to WooCommerce > Settings > Checkout screen. Uncheck the Enable guest checkout setting.
• Registration: We funnel user registration through https://robotninja.com/register/ which uses a custom Gravity Form for user registration (it’s easy to customize and integrate with third party applications like Slack). We needed to stop customers signing up via other places on our store. To do that, on the WooCommerce > Settings > Accounts screen, we unchecked the Customer registration settings.

And that’s about it. All the other features in WooCommerce, from tax calculations to emails were helpful additions for our SaaS billing platform.

Now that we’d configured WooCommerce and set up a streamlined checkout process, we were ready to start charging for our SaaS with WooCommerce. At least that’s what we thought…

Curve Ball: Test Card Deposits

There’s always a gotcha.

In the case of Robot Ninja, it was creating a simple way for customers to add additional amounts to their test card.

Robot Ninja provisions a real debit card for each customer to test live payments. This is in part what the $79 sign up fee covers when upgrading to a pro account and unlocking live payments.

To handle testing products for more than $79, customers need to deposit extra funds on their test card. If we didn’t do this, a malicious actor could exploit the test cards to steal money. The test debit cards use real money. A malicious actor could choose to test purchases of product for a large amount, say $500. If they blocked the refund process, they would keep the payment made to test that product.

To avoid this, we needed a way to top up a test cards. We wanted this process to be as simple as possible. One or two clicks. No cart. No checkout.

WooCommerce APIs to the Rescue!

Remember how I talked about that handy `WC_Order` object earlier? An order also happens to be the perfect object to record a test card deposit transaction. Especially as WooCommerce’s refund functionality makes it easy to return deposits.

With Subscriptions, we also had existing APIs to both:

1. create an order linked to a subscription, and
2. pass it to the payment gateway to process payments.

With these APIs were able to charge the credit card linked to the customer’s subscription and create an order to record that transaction. No cart or checkout needed. Only a few lines of code needed, thanks to the existing APIs. This made it possible to create the simple test card top up process we hoped for.

The majority of the code went to customizing the order. We used a fee line item to record the payment, rather than linking it to a product line item. This made the most sense as the deposit was not a taxable sale of a product.

Is WooCommerce Good for SaaS Billing?

We’ve been very happy with our choice to use WooCommerce for SaaS billing. It allowed us to achieve the ideal billing system, despite its complexity. We were also able to handle unforeseen technical requirements without any trouble.

Choosing WooCommerce also integrates our billing system with the content management system and the hub of our application. We don’t have to integrate a separate billing system through REST APIs and webhooks. We don’t have to login to a separate website to refund deposits or view sales reports.

Time will tell if we made the right decision. Managing a WooCommerce store is more difficult than creating one. For now, I’m confident recommending WooCommerce as a SaaS billing solution, provided the team implementing it have existing WooCommerce development experience.

We knew WooCommerce and Subscriptions core code so well that it was a natural choice for us. I don’t imagine it is the right choice for everyone.

As more agencies develop advanced WooCommerce skills, it will become easier to use WooCommerce for more complex billing system. Especially if developers release more SaaS-related functionality, like the Subscriptions Resource library.