Monetizing APIs with WSO2 API Manager

Today APIs have become a key way for application developers to generate revenue, meaning monetisation is becoming a sought-after feature in the API Management space. Even though API monetisation has a broader meaning than simply charging for APIs; in our experience, most companies want to charge for API usage. There are a number of different ways that this can be achieved, but let’s take a look at the two most popular and how they can be effectively rolled out to bring in revenue.

Under this model, a fixed amount is charged from the application developer at the end of the billing cycle, where a certain number of calls are allowed per month. Irrespective of whether they use these or not, they will be charged. This model suits purchasers who prioritise full visibility and certainty around costs, with no “nasty surprises”.

Subscription-based charging can be further broken down into two models. Tiered pricing and Freemium. In tiered pricing, different request quotas can be sold for different prices. For example, when implementing this model, you can create three tiers: Bronze, Silver, and Gold. They can be priced at £25, £40 and £60, which would offer bundles of 1000, 2000, and 3000 requests per hour. 

When it comes to the freemium model, you offer a free tier with a stringent limit on the request quota and a paid tier that offers a higher quota. For example with freemium model you can introduce a free tier, with 100 requests per hour and offer the other tiers for a price. Depending on your requirement, you can choose to either block the additional requests or continue the flow when the quota depletes.

In this model, price is calculated based on the number of requests made. This model is also known as a “pay-as-you-go” model, where there’s no fixed payment. If the pricing is set at £0.01 for a single request, and then if 1000 requests are made during the month, a user would be charged £10. There is no fee if no requests are made. This model suits purchasers for whom more requests equal more revenue, so the payment per request effectively becomes part of cost of sales, to use accounting terms. It means the purchaser doesn’t run the risk of paying for requests that are never made. 

Implementing these models requires integrating an API manager capable of gathering and publishing usage data with a billing and collection engine, such as Stripe, to charge the customer. Here’s an example of how it works:

The API Manager uses Stripe to manage interactions between API providers and Consumers. From Stripe’s perspective, the API Manager operates as a platform. Therefore, as a part of the configuration, an admin for the API Manager needs to create an account and configure it as the platform account. API providers would also have to create accounts in Stripe and link it with the platform account using Stripe Connect, which gives the ability to the admin to charge consumers on behalf of an API provider.

When charging for API usage, two parties are involved: the API provider, who hosts the API and who is responsible for the upkeep and management of the API, and the API consumer, the party that uses the API. API consumers would use an API through an application. In a typical paying scenario, API consumers would pay API providers for using the API.

As the first step of configuring, the admin needs to create an account and configure it as the platform account. API providers would also have to create accounts in Stripe and link it with the Platform Account using Stripe Connect, which gives the ability to the admin to charge consumers on behalf of the API provider. 

Once you have done the configuration, you can start charging for APIs simply by creating billing plans in the admin portal. Simply fill in details such as how much you need to charge and what charging model (subscription, pay as you go) you want to follow. You can also specify the request count and whether to block the invocations once the allotted quota is depleted. 

Then, API providers can log into the publisher portal and select the billing plans they want to enable. While saving the API, they also have to provide an ID that maps the account at Stripe’s end. Hey presto! You have created an API that can be charged for.

When creating a billing plan through the admin portal, a corresponding pricing plan will be created on Stripe. This will be created via the Platform Account (the account created by the Admin), so that the plans are available to different API providers.

And then, the API provider can enable monetisation and select a plan for the API. When doing this, a matching product with the API’s name will be created in Stripe; the selected pricing plans will be added into the product. These products are created in the API provider’s account. 

Next is the part performed by the API consumer (or the application developer). When an app developer logs into the Dev portal and creates an application, a matching customer object is created in Stripe. So, for each application created, there is a separate customer object, bearing the payment details specified by the API consumer.

At the time of subscribing to the API, a subscription will be created on Stripe, under the product corresponding to the API, with the billing plan selected. This ensures that the API accesses are charged according to the billing plan as usage data is published.

Using an API manager to integrate with a billing engine is a neat and seamless way to monetise your API. At WS02 our API Manager 3.0.0 has been developed to help you quickly and easily monetise APIs by integrating with any billing engine – it supports Stripe out-of-the-box - so you can offer the right consumer pricing and subscription model to your market, in record-quick time.