Today APIs have become a key way for application developers to generate revenue. This means monetisation is becoming a sought-after feature in the API Management space. The simplest form of monetisation is to charge a one-off fee or a fixed license fee. However, most companies want to charge for actual API usage.
Subscription charging
There are different types of subscription charging that can be applied for usage such as a flat fee per month, quarter or year or a tiered fee per month, quarter or year and/or a freemium model. Or the fee could be worked out as a charge for a bundle of usage or charging can be simply usage-based. For example, under a flat fee charge, the application developer is often charged 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”. However, the question is what happens if they exceed this monthly usage? Often, if the customer exceeds the cap they pay more and their monthly limit is increased, or sometimes they have to pay a one-off penalty for exceeding the limit.
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.
In a freemium model, you offer a free tier with a strict limit on the request quota and a paid tier that offers a higher quota. For example, with a 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 a block of additional requests or continue the flow when the quota depletes. How long you can do this very much depends on the price that you pay.
Charging per request
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 the 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.
How the integration works
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.
- 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.
Here’s an example of how this could work with Stripe:
Integration with Stripe
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.
With this 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 or pay as you go) you want to follow. You can also specify the request count and whether to block the calls 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.
Start using the APIs
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 multiple API providers.
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.
Integrating with a billing engine
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 can help you quickly and easily monetise APIs by integrating with a leading 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.
Founded in 2005, WSO2 is one of the world’s best open source integration vendors, helping digitally driven organisations become integration agile. WSO2 is a global organisation with offices in Europe, the Americas, Sri Lanka and Australia.
WSO2 solutions give enterprises the flexibility to deploy applications and services on-premises, on private or public clouds, or in hybrid environments and easily migrate between them as needed. All of the products are pre-integrated allowing enterprises to focus on value-added services and get to market faster.
