From our extensive experience in the API management space, we see that digital-driven organizations are now continuously seeking creative ways to monetize services and assets through APIs. Within this context, 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).
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. Freemium and tiered pricing.
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. The freemium model allows you to introduce a free tier, with 100 requests per hour. Depending on your requirement, you can choose to either block the additional requests or continue the flow when the quota depletes.
Charging per request
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.
Using WSO2 API Manager for charging
With the 3.0.0 release, WSO2 API Manager supports monetization as a first-class feature.
This is achieved by leveraging the strengths of external billing engines, such as Stripe, for billing and collecting, while relying on WSO2 API Manager’s capabilities to gather and publish usage data.
If you are familiar with these features and are excited about trying them out, you can download the latest product from here and start following the doc. However, if you find the document too technical, this article aims to provide a more high-level overview, explaining the need for different configurations and how certain features in Stripe are used while implementing billing.
Integration with Stripe
WSO2 API Manager seamlessly integrates with Stripe. With only a few configurations, the product takes care of creating Products, Plans, and Subscriptions needed for billing.
WSO2 API Manager publishes usage data while Stripe performs billing and collecting.
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.
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. The section on Configuring the Billing Engine provides details on this.
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.
Refer to the section on Creating a Subscription Policy for more details on this.
Creating a subscription-based billing plan on WSO2 API Manager
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.
This is covered in detail under Enabled Monetization.
Applying billing plans for an API
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.
For more details look at Subscribe to a Monetized API.
Now that the basic configuration has been done, let’s consider how charging happens.
Even before billing was introduced, WSO2 API manager had the framework to gather usage data and aggregate them according to different requirements. When billing is enabled, the same underlying framework is used to gather usage data. Such gathered data will be published to Stripe in a pre-defined frequency.
This section gives you more details to publish data on Stripe.
If you are interested in seeing a live demo, please contact our marketing team to request one. Or else, if you are excited to try this out yourself, you can download the latest version through this link
What happens underneath
You don’t need to understand the internal details about billing to make it work. However, if you are interested about what happens underneath or want to understand the internals with the aim of customizing 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 until an explicit command is run 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.
We hope that you got a good idea about the new monetization feature and how WSO2 API Manager integrates with Stripe. If you have any questions on Monetization or in general about API Management, feel free to contact us through https://wso2.com/contact/.