With APIs becoming a focal point in generating revenue, monetization is becoming a sought out feature in API Management space. Even though API monetization has a broader meaning than simply charging for APIs; in our experience, most companies want to charge for API usage.
WSO2 API Manager 3.0.0 provides first-class support to monetize APIs. It gives the flexibility to plug in any billing engine, and out-of -the-box the product integrates with Stripe—which is a service that allows individuals and businesses to make and accept payments online. Keeping up with market demands, API Manager 3.0.0 supports two widely popular models to charge consumers (i.e., application developers)
- Charging per subscription
- Charging per request
Charging per subscription
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.
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 USD50, USD100 and USD150, 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.
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 USD 0.01 for a single request, and then if 1000 requests are made during the month, a user would be charged USD 10. There is no fee if no requests are made.
Let’s see how API Manager can be used to implement these models.
Using WSO2 API Manager for charging
WSO2 API Manager supports monetization by leveraging the strengths of external billing engines, such as Stripe, for billing and collecting, while relying on its inherent capabilities to gather and publish usage data.
Integration with Stripe
WSO2 API Manager uses Stripe to manage interactions between API providers and Consumers. From Stripe’s perspective, WSO2 API Manager operates as a platform. Therefore, as a part of the configuration, an admin for WSO2 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.
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, 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. We use features like accounts, customers, and subscriptions available in Stripe to depict this relationship.
Once you have done the configuration, you can start charging for APIs simply by creating billing plans. You log into the admin portal and create a billing plan, filling in details such as how much you need to charge and what charging model you need to follow. You can also specify the request count and whether to block the invocations once the allotted quota is depleted.
While creating billing plans, you get to choose whether you are going to charge for the subscription or charge per request. But, based on how you engaged the billing plans, you can provide a freemium model or the tiered pricing model.
Then, API providers would 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. By this point, you have created an API that can be charged for.
To use these APIs, application developers (API consumers) would have to log into the developer portal and subscribe to those. There are a few additional steps, such as entering payment methods and billing information, but, finally, application developers will be charged based on the plan they subscribe to.
Now that the basic configuration has been done, let’s consider how charging happens.
As requests flow through the API Manager, stats on those are collected and stored by the Analytics framework in real-time. Long before billing was introduced, WSO2 API manager had the framework to gather usage data and aggregate them according to different requirements. And the new billing feature simply uses the same underlying framework to gather and process usage data. Gathered data is published to Stripe in a pre-defined frequency.
What happens underneath
You don’t need to understand the internals to make billing work. However, if you are looking to customize the flows, this section tries to shed more light on how different elements in Stripe are used to implement billing.
We use the following features/elements available in Stripe.
Product – Represents a real-world product or a service. A single product can be defined with different pricing plans.
Customer – A party who uses a product. In order to proceed with charging, billing details need to be provided.
Subscription – Before using a product or service, a customer needs to subscribe with a pricing plan.
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 monetization 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. Recall that when configuring, we had to specify the connected account ID, which is used in this case to create the products and add pricing plans on behalf of the API provider.
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 would be 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.
There’s something to be said about publishing usage data. While the requests flow through the gateway, relevant billing plans and associated data get pushed to the analytics nodes. Now, analytics would summarize this data by different time intervals and update the DBs. But unless a command is issued to push this Data, Stripe will not receive any updates about the usage. Depending on how frequently you run the billing cycles, you can schedule a job to push usage data.