A Playbook to Properly Implement Pay As You Go Pricing for Your API Product
Pay As You Go (PAYG) is a relatively new SaaS pricing model that drives growth and revenue. Learn what pricing model fits your API product and best practices.
Join the DZone community and get the full member experience.Join For Free
Usage-based pricing, consumption-based pricing, and PAYG (Pay As You Go) are relatively new SaaS pricing models that enable you to drive top-of-line growth while also increasing net revenue retention over more traditional subscription pricing models such as license or seat-based pricing. With Pay As You Go, a customer only needs to pay for what they consume such as hours of a VM or number of messages sent. APIs naturally are transaction-based, which make them suitable for new consumption-based pricing. In fact, all three cloud providers (AWS, Google, and Azure) leverage consumption-based billing so their customers can optimize their infrastructure.
Prepaid vs. Postpaid Billing
First, you’ll want to decide whether you want prepaid or a postpaid billing. Prepaid billing requires the customer to purchase credits or pre-negotiated quota ahead of time creating a positive balance that is then “burned down.” If they are credits, a customer will need to periodically top off their account by purchasing additional credits before they run out. Some systems enable “automatic top off” once a balance falls below a defined threshold. This can improve your business cash flow since you’re able to leverage the spent capital even before any costs are incurred to deliver their service. Irrespective of Pay As You Go, most enterprise companies require enterprise contracts to be prepaid for the term as prepaid enables more payment options such as a bank wire or ACH. Customers also benefit since they can set hard budgets for your service and disable any “auto top off” functionality.
The downside to prepaid billing is the additional friction added when purchasing a plan when usage is not predictable, especially if it’s not a bundled amount. Prepaid billing requires the customer to estimate how much to purchase even before even using the service which can also cause more refund requests if they don’t end up using the credits. Unless a card is on file, collecting additional fees due to overage or term violations may be harder. Customers may be opposed to prepaid billing since the capital is tied up. This can be especially true for growth-oriented spend such as pay-per-click advertising or credit card processing. In these cases, a customer may be willing to pay a higher price since they already collected the revenue from their users.
A third option is to leverage a hybrid of both. For example, a bundled amount could be prepaid on a credit card, but then overage fees are postpaid.
You will also need to decide how often a customer is billed which is related to whether you leverage prepay vs. postpay billing. One option is to invoice periodically such as the nth day of the month. This makes it easier on your customers’ billing department as your service more predictable while minimizing extra work to pay invoices. This is also easier to understand as most SaaS subscriptions are already billed annually or monthly.
It’s not recommended to have a common billing day for all customers like the start or end of a month, as this can cause your support team to deal with a flood of billing requests on that day.
A second option is threshold based. If prepaid billing, a customer needs to purchase credits which in turn needs to be topped off once the balance drops below a threshold. Many systems allow this to charge a card automatically such as When the balance drops below $10, add $100 worth of credits. If you implement postpaid billing, the threshold is simply the reverse in that when the negative balance goes above a threshold such as $500, an invoice is generated and credit card charged. This is increasingly common in self-serve advertising. The downside is a lack of predictability, since some months could have many more charges than other months. If not careful, this can generate an unnecessary number of invoices with small charges. Similarly, this can cause a nightmare for your accounting team and harder to predict future revenue.
Based on your billing time and frequency, you will need to implement a system that can accurately measure and report on transaction volume for each customer account. This usually means having an analytics system on API calls or transactions. Because each customer may have a different billing period, your analytics solution should have a way to handle this. If you leverage periodic billing, then you can query a customer’s usage when you invoice them which is usually on a predefined billing day.
For threshold billing, measurement may be a little more tricky since an invoice can be generated at any time, not just on the customer’s billing day. This means you need to keep track and trigger invoices once the threshold is reached. Leveraging a ready-made API analytics tool like Moesif can reduce your development and maintenance time drastically vs a custom in-house billing.
When it comes to pricing, customers don’t want surprises. Yet, with consumption-based billing, invoice amounts can vary depending on their usage. By sending automated quota and usage emails, your customers can stay informed when their cost increases or they approach a quota limit.
If you leverage a hybrid model such as a bundled fee and an overage fee, you may want to remind customers once they used the majority of their quota or when they exceeded it. A behavioral email platform like Moesif can be configured to silence notifications for a period (like 10 days), one a customer gets alerted to avoid spamming your customer’s inboxes. Then after 10 days, if a customer is still exceeding the limits, you can send a second email.
Self-Serve Billing Dashboards
Because you are billing based on usage, it’s imperative to provide your customers with visibility into these usage and success metrics in a self-serve way. Rather than force your customers to ask for support just to understand how much quota they used, you may be able to embed metrics right inside your developer portal. Your customers will want to slice and dice this data so that they can understand where their usage is going and where they can save money.
Requirements for usage reports include:
- Ability to see usage by different intervals like hourly, daily, or monthly
- Shows number of business transactions, even if your API can handle requests in batch
- A way to break usage down by user demographics or clients.
Beyond usage reports, you can also embed other metrics like SLA, API logs, and more to improve your developer experience and reduce barriers to adopting your API platform.
Pay As You Go pricing can drive both revenue and retention for your business with implemented properly. Yet, consumption-based billing is also more challenging to implement than more traditional subscription pricing. You need accurate measurement of usage and also workflows to ensure your customers are not surprised once they receive an invoice. Tools like embedded charts and quota emails can go a long way to keeping your customers informed.
Published at DZone with permission of Derric Gilling. See the original article here.
Opinions expressed by DZone contributors are their own.