Add monetization ability of API
It is a common practice for API service developers to link the resource counts or product plans to pricing. The preference is for either integration ability to 3rd party services (ex. Braintree) or direct implementation so API developers can collect payment for services.
Is there an update on this? I'd like to know a rough idea on the roadmap for this, as this will determine if I have to write the functionaility myself.
Cabdiqaadir Barwaaqo commented
What is this
Does Azure API Management now provide billing and pricing for APIs or does one has to integrate third party billing app/apis? Any case studies please
A more integrated, non restrictive solution would be obviously welcomed, and you are pretty close to it!
I see a very important miss in what we can build today: There is actually no way to give the customer a way to find his invoices (from Stripe or whatever), even with the developer portal custom tools, unless i am wrong?
Also, how/where the customer should update his credit card (after he entered it thought a product suscription for example)
Can you confirm that, and what do you suggest?
"overages" are just additional calculations
Please also consider supporting "distinct(X)" pricing. For example my api may have a Region parameter, and my pricing is "$50 per distinct region used during monthly billing period". So consider implementing for metered billing a calculation engine across API invocations that supports functions like "Distinct" and "Count". This calculation engine needs to be expressive - support conditionals, "select case" expressions, etc. Make it expressive from the get-go and we won't be pestering you features.
Ideally both pricing tier and metered will be supported. Many customers need tiers so that they can get approval for a fixed monthly price.
I think Stripe and Braintree and perhaps a couple others should be pre-integrated and available - but please make the source for those integrations open-source so that we can use as a starting point and modify.
Shiran Ginige commented
I tried APIManagement about an year ago and lack of monetisation put me off. It is a must have for developers to do anything serious with it.
Gururaj Pandurangi commented
Any thoughts on this?
Without a multi-tenancy monetization model, API management would not be a great fit for the APIs we are building. We prefer to not end up in Apigee or Mashery world.
Are there any plans for monetization?
Chris Harrington commented
Asking this question again a year+ later
Nicolas Kirrmann commented
Definitely a must have feature
Anything came out from the review 8 months ago?
This capability is a must.
Gregory Harris commented
I add my voice to those considering that this is a mandatory capability.
Without it I guess I'm back to looking at Apigee and the like...
Has this been added to the tool? I am still not getting how can I monetize the use of my API. Does the Azure API Management tool provide a way to do this? Or I have to delegate it to my own site in order to do so?
John Phillips commented
Being able to add delegated billing or access to the billing data is crucial.
Scott Hunter mentioned in an Azure Friday video about plans to help developers monetize their APIs. Some sort of App Store for APIs would be brilliant. Being able to charge a monthly fee AND having the option to charge per call, per 100 calls, per 1000 calls would free developers to get on with developing.
Jorge Alvarado commented
Currently Azure API Management allows management of subscriptions (for API clients) based on the approval of API Developer Console administrators or without requiring any approval at all.
If a developer wants to monetize his API, it is necessary to handle the payment plans based on those subscriptions.
There is no built-in feature that helps developers to manage payments and billing of their own API customers.
While I can potentially build out my own integration with billing providers, it would be far more useful to allow integration with 3rd party providers, or Microsoft. I don't see this as a deal breaker, but it does add a layer of complexity to an otherwise straightforward solution.