Prepaid billing

Prepaid is the most common model for traditional softare-as-a-service (SaaS) and enterprise software companies. Because the API provider gets cash upfront before any services are rendered, prepaid models can be a lifesaver for the business as they can increase cash flow. This is especially important if your acquisition or setup costs are high, which allows you to invest further into product and growth. Prepaid is also beneficial for customers as it provides spend predictability and reduces the processes involved for procurement. Because usage amounts are unknown before payment is made, you can handle usage-based billing through a committed spend. This might include volume discounting. However, prepaid might force a customer to do mathematical estimates before they have real-world data.

Postpaid billing

On the other hand, postpaid is where you’re extending credit to your customers as they use your platform until they pay. Postpaid can simplify consumption-based business models since a customer doesn’t need to guess how much they will consume. Instead, they can just enter their credit card and deal with the bill later and see how much the damage was (like dining at a restaurant or bar). Postpaid billing has been popularized by consumption-based models, like the digital advertising industry and, more recently, the cloud industry. A benefit of postpaid is that a customer does not need to commit ahead of time before any value is seen.

However, there is a downside. Because you’re extending credit, it can be abused by customers depending on your offering (like a dine-and-dash scenario). Having good safeguards and limits is important to ensure a customer doesn’t accumulate too much credit before they purchase. Postpaid can also have higher cancellation rates. A customer could use much more of an expensive service than expected and then have regrets.

The following table shows some of the pros and cons of each approach:

Tiered pricing

Classic tiered pricing makes it easy for customers to understand their costs and makes pricing more predictable, a plus for large companies purchasing software. It’s common and well understood within the SaaS industry, reducing complexities around billing. In addition, it’s super easy to implement. You don’t need any metering or analytics to track usage. You can just implement a subscription billing software solution.

The issue with tiered pricing is the disconnect between price and perceived value. As a customer comes close to the limits of their plan, they naturally should upgrade their plan. However, the price jump to the next plan can be significant, which can cause scenarios where the customer doesn’t feel ready for the next tier. This can be exaggerated if the tiering utilizes too many variables. It’s uncommon that a customer will exceed all limits of a plan and will instead exceed only one quota limit. However, the next plan has “too many extra items” that the customer doesn’t need (such as additional features). Similarly, you don’t want more than three or four tiers. If you have too many, it creates analysis paralysis.

Pay-as-you-go (PAYG) pricing

Because of these issues with tiered pricing, a more modern approach is being utilized where customers pay for their usage. Consumers have utilized physically metered plans for quite some time, like gas and electric utilities. This concept of metering can be applied to digital products that have a usage-based component. Common things to meter on include transaction volume, gigabytes sent, or unique users.

A benefit of usage-based pricing is that the price to perceived value gap is significantly reduced as customers only pay for what they need. PAYG is a great accelerant for product-led growth or developer-first businesses. You can design a self-service plan that hooks in customers and then allows them to grow their usage over time. In other words, your pricing model has built-in expansion revenue. However, PAYG can be challenging without knowing what is going on in terms of customer usage levels. Moesif’s analytics is one solution that can meter API usage and automatically invoice customers through a provider like Stripe. See this guide for a step-by-step guide on how to implement prepaid with PAYG.

The following table lists some of the pros and cons of tiered and PAYG pricing:

Choosing the right usage metric

With usage-based pricing, it’s important to choose the right metric to meter and bill on so that it’s correlated with the business value received. Billing for every API call is likely a poor metric since some APIs are low value (such as a status probe). Similarly, you might offer both a batch and nonbatch API. If you’re building an SMS API offering, then a single API call that sends 100 SMS messages as a batch and then transcribes them creates a larger amount of value for the customer than an API call that sends just a single SMS message. In this case, billing based on number of SMSs sent would be a better metric than billing on number of API calls.

As a secondary example, let’s say your API handles sending marketing emails but also provides the ability to store email templates in the platform. If you bill based on number of templates stored, that might be a bad metric as it’s unlikely a customer receives value simply by storing additional templates in the tool. If the customer drafted a massively large number of email templates but never sent a single email through the API, their bill would still be large. On the other hand, customers sometimes have strange behavior, like consistently deleting old email templates after they’re sent even though it would have been better to keep the email template in the tool. In this case, customers get value by automating the process of sending marketing emails. Thus, a better metric aligned to customer value would be the number of unique contacts emailed per month or number of emails sent per month.

Invoicing strategy

Invoicing strategy impacts cash flow and is typically driven by the financial team the most. Once you decide on a billing model and how your offering is packaged, you’ll want to determine when invoices are triggered and generated. Unlike billing and packaging, which have an impact on product and expansion revenue, invoicing strategy has a larger impact on unit economics. With recurring invoicing, you invoice the customer on a schedule such as per month or per year. On the other hand, you can also invoice customers once they reach a threshold, such as when they reach a certain quota or outstanding spend. This type of invoicing is called threshold-based invoicing.

Recurring invoicing

Recurring invoicing is the more popular of the two and easy for customers to understand. You can invoice them in a prepaid way (which is usually a fixed price) or send a bill for what the customer’s usage was for the prior billing period. For buyers of enterprise software, recurring invoicing is usually preferred as it’s predictable and easier to plan for. There are a couple of downsides, which usually come up with extreme PAYG models. If you have some customers with extremely low volumes, where they are paying only a few pennies or dollars per month, the transaction fees will exceed the cost of service. Similarly, if a customer can quickly rack up a lot of credit within a billing period, or the value received is very transactional, this could create a large accounts receivable balance in between billing periods, even though the service has since been rendered. This is common in the digital advertising industry where large spends can accumulate quickly.

Threshold-based invoicing

In order to combat the poor unit economics of recurring invoicing, threshold-based invoicing can be leveraged. With threshold-based invoicing, the invoice is not generated until a certain threshold is reached. If prepaid, this means a customer is purchasing credits which can then be used (which might be far in the future). If postpaid, the invoice is generated after a threshold is reached, such as $1,000 in ad spend. This ensures you only have up to $1,000 outstanding for a customer at a time, regardless of their monthly spend. Threshold-based pricing is not without downsides. It can heavily complicate accounting, since the spend is not predictable and not exactly aligned to a billing period like quarterly or yearly. The time could be open ended and not well defined.

This table lists the pros and cons of both types of invoicing:

1. Identify customer impact

The first step is to understand the impact from the deprecation using API analytics. You should have a good grasp of who is using the soon-to-be-deprecated APIs and how it impacts customers’ implementations. At a bare minimum, you should understand what percentage of your customers are actively using the deprecated feature. However, simply measuring counts of API calls is not sufficient. You should have a quantifiable business metric to measure impact, such as potential lost revenue and cost to support the deprecation effort.

2. Announce the deprecation plan

Once you’ve decided to move forward with the deprecation, you will need to announce your deprecation plan to your customers. This should be published on your project blog, changelog, internal wiki, or any other channel that customers turn to for information. It’s highly recommended to email customers directly and overcommunicate rather than risk upsetting someone later.

You should also mark the endpoints as deprecated in any developer docs or API reference that you have.

3. Email customers when they use the deprecated API

Even though you announce the deprecation via email or blog, not everyone will view the announcement or they may forget about it. This is where providing a personalized customer journey based on their API behavior is critical. Each time a customer uses the deprecated feature, let them know right then. This can be done through a combination of HTTP response headers and behavioral emails (customer lifecycle emails).

To make it easy for your customers to migrate, it’s recommended to include helpful info like which deprecated APIs were accessed, volume, and the user agent. These emails can be automatically configured using a platform like Moesif or HubSpot. It’s recommended to set up a recurring workflow to remind customers periodically if they continue to utilize the deprecated API.

4. Warn customers using HTTP response headers

Even if you send warning emails to every customer in your database, sometimes the person responsible doesn’t receive it since the developer’s contact information is no longer valid or emails got sent to spam. The recommended way to ensure the appropriate developer receives the deprecation notice is by in-app notification. While the first thing you may think of is an in-app portal, not everyone logs into an API provider’s dashboard on a regular basis.

5. Implement a brownout strategy

You can never overcommunicate a change that could break a customer’s integration such as API deprecation. However, sometimes the developer still does not take action. One way to semi-force customers to do something is with a brownout or rolling-blackout strategy. This strategy turns off access to the feature or service temporarily, such as for 15 minutes on Tuesday at 6 p.m. PST. This will help trigger any alerts and alarms that your customer may have set.

It’s recommended to enforce a brownout when the chance a developer is at a computer is high, when they can take action quickly but end user impact is minimal. If you expect a large number of support tickets, you can implement a rolling blackout where only select customers at a time are shut off rather than everyone, just like a rolling power outage that’s planned during very high demand, such as in heat waves.

6. Monitor usage to see if safe to deprecate

Now that you executed the majority of your deprecation plan, it’s a good idea to analyze how usage of the deprecated endpoint is trending to see if it’s safe to follow through with shutting off access permanently. Hopefully by this stage, not many customers are accessing the deprecated endpoints or features. You may have a few stragglers, which are ghost services that are no longer maintained, but it’s better to be safe and fully understand who is still using the endpoints.

If the API users are critical customers, you may need to delay your shutoff date for a period to work with those customers. Large customers with complex systems are sometimes the last to migrate. This can be done easily using an API analytics tool.

7. Shut off access to the feature

Now that you’ve added all the steps to properly sunset the feature, it’s time to permanently shut it off. Check one last time to ensure no adjacent services are erroring out due to dependencies that were not realized earlier. Congrats, you correctly went through the steps to sunset an API.