Re: [Architecture] [APIM][Monetization] Monetization Model For WSO2 API Manager
Hi Shammi, How we are going to handle failure cases with this plan. To handle the failures internally inside APIM , we must configure a webhook endpoint at the APIM side and must listen to the relevant events which are triggered from Stripe at the occurrence of such an event. But in this feature we are trying to provide a more generalized approach by omitting the most of the stripe specific things. Since this is very stripe specific, we are currently assuming that this should be manually done by the provider in Stripe dashboard and APIM will not include inbuilt support. When it comes to distributed deployments with many nodes with multiple timezones, EU/APAC/ US, Are we aggregating the counts per local timezone? We should aggregate the usage count on the same time zone in which subscription is created , otherwise there can be billing cycle mismatches. The stripe account time zone is configurable and the provider must configure his Stripe time zone to UTC before subscriptions are created , and we publish usage records on UTC time zone. - Hope this call to the count table be asynchronous , Are we implementing this caull as a handler in response path or what is the plan? I assume you are referring to analytics tables as count tables, this is implemented an admin API for now . On Thu, May 23, 2019 at 9:21 AM Shammi Jayasinghe wrote: > Hi, > How we are going to handle failure cases with this plan. > > eg: > - for the monthly plan, If the subscriber has not paid or can not be > charged from the CC, Is stripe will send back the call to API M to block > that subscription? > - If the subscriber paid later, how we are going to re-activate > > - When it comes to distributed deployments with many nodes with multiple > timezones, EU/APAC/ US, Are we aggregating the counts per local timezone? > - Hope this call to the count table be asynchronous , Are we implementing > this call as a handler in response path or what is the plan? > > Thanks > Shammi > > > On Wed, May 15, 2019 at 7:21 AM Frank Leymann wrote: > >> Would a discount pricing model make sense? E.g. after x requests you get >> a discount of y%? >> >> And what about adding a QoS aspect: if x requests failed within y >> duration, you get a discount of z% for D duration? >> >> Best regards, >> Frank >> >> >> >> >> Am Mi., 15. Mai 2019 um 08:21 Uhr schrieb Chamin Dias : >> >>> Hi all, >>> >>> Based on the recent discussions we had, we will be going to implement >>> the following features from the products POV. Intention of this email is to >>> give an update on some of the important points. >>> >>> *A) Model : Charge a fixed price for a given time* >>> >>> *1. What we need in the product : * >>> Ability to define the fixed price, frequency and duration for a tier >>> Eg : $25 (price) per 1 (frequency) month (duration) >>> >>> Note : This can be extended as "one time payment" if needed. That means, >>> if we specify something like, "$25 (price) per 100 (frequency) years >>> (duration)" - it will charge $25 per 100 years. Practically a subscription >>> won't last that much of time so this can be considered as one time payment >>> for a tier. >>> >>> *2. What we need in the billing engine : * >>> Ability to define pricing plans with parameters (price, frequency and >>> duration) >>> >>> *3. Benefit / User experience : * >>> Admins will define tiers with using the dashboard. >>> API providers can attach a tier with fixed price (for a given time). >>> Subscribers will pay a fixed amount (per week, month - specified in the >>> tier). >>> >>> >>> *B) Model : Pay as you use* >>> >>> *1. What we need in the product : * >>> i) Ability to define the price per request >>> ii). Aggregate usage daily (via a scheduled / manual task) >>> >>> *2. What we need in the billing engine :* >>> Ability to define pricing plans with 'pay as you use' mode and aggregate >>> or set usage and charge subscribers for the usage. >>> >>> *3. Benefit / User experience : * >>> API providers can attach a tier with 'pay as you use' type. Then, usage >>> will be aggregated daily / or set for each subscriber. At the end of each >>> month, subscriber will be charged for the aggregated usage. >>> API provider will be able to see the revenue from each user of their API. >>> >>> Thanks. >>> >>> On Mon, Apr 8, 2019 at 3:10 PM Chamin Dias wrote: >>> Hi Cyril, As for the initial implementation, we plan to provide this integration with stripe but eventually we hope to provide necessary interfaces to extend. For now, we focus on delivering a workable solution (APIM + Stripe) for a normal usage based billing scenario. Thanks. On Fri, Apr 5, 2019 at 3:53 PM Silmy Hasan wrote: > Hi Rukshan, > > Please my answer to your concern below > > *I think we can reuse the existing data. Even though we define > recording policy, all the possible data is stored in the analytics DBs > regardless of the recording policy. So
Re: [Architecture] [APIM][Monetization] Monetization Model For WSO2 API Manager
Hi, How we are going to handle failure cases with this plan. eg: - for the monthly plan, If the subscriber has not paid or can not be charged from the CC, Is stripe will send back the call to API M to block that subscription? - If the subscriber paid later, how we are going to re-activate - When it comes to distributed deployments with many nodes with multiple timezones, EU/APAC/ US, Are we aggregating the counts per local timezone? - Hope this call to the count table be asynchronous , Are we implementing this call as a handler in response path or what is the plan? Thanks Shammi On Wed, May 15, 2019 at 7:21 AM Frank Leymann wrote: > Would a discount pricing model make sense? E.g. after x requests you get a > discount of y%? > > And what about adding a QoS aspect: if x requests failed within y > duration, you get a discount of z% for D duration? > > Best regards, > Frank > > > > > Am Mi., 15. Mai 2019 um 08:21 Uhr schrieb Chamin Dias : > >> Hi all, >> >> Based on the recent discussions we had, we will be going to implement the >> following features from the products POV. Intention of this email is to >> give an update on some of the important points. >> >> *A) Model : Charge a fixed price for a given time* >> >> *1. What we need in the product : * >> Ability to define the fixed price, frequency and duration for a tier >> Eg : $25 (price) per 1 (frequency) month (duration) >> >> Note : This can be extended as "one time payment" if needed. That means, >> if we specify something like, "$25 (price) per 100 (frequency) years >> (duration)" - it will charge $25 per 100 years. Practically a subscription >> won't last that much of time so this can be considered as one time payment >> for a tier. >> >> *2. What we need in the billing engine : * >> Ability to define pricing plans with parameters (price, frequency and >> duration) >> >> *3. Benefit / User experience : * >> Admins will define tiers with using the dashboard. >> API providers can attach a tier with fixed price (for a given time). >> Subscribers will pay a fixed amount (per week, month - specified in the >> tier). >> >> >> *B) Model : Pay as you use* >> >> *1. What we need in the product : * >> i) Ability to define the price per request >> ii). Aggregate usage daily (via a scheduled / manual task) >> >> *2. What we need in the billing engine :* >> Ability to define pricing plans with 'pay as you use' mode and aggregate >> or set usage and charge subscribers for the usage. >> >> *3. Benefit / User experience : * >> API providers can attach a tier with 'pay as you use' type. Then, usage >> will be aggregated daily / or set for each subscriber. At the end of each >> month, subscriber will be charged for the aggregated usage. >> API provider will be able to see the revenue from each user of their API. >> >> Thanks. >> >> On Mon, Apr 8, 2019 at 3:10 PM Chamin Dias wrote: >> >>> Hi Cyril, >>> >>> As for the initial implementation, we plan to provide this integration >>> with stripe but eventually we hope to provide necessary interfaces to >>> extend. For now, we focus on delivering a workable solution (APIM + Stripe) >>> for a normal usage based billing scenario. >>> >>> Thanks. >>> >>> On Fri, Apr 5, 2019 at 3:53 PM Silmy Hasan wrote: >>> Hi Rukshan, Please my answer to your concern below *I think we can reuse the existing data. Even though we define recording policy, all the possible data is stored in the analytics DBs regardless of the recording policy. So we should be able to correlate this recording policy with stat data and filter out required data from the Billing engine.* As discussed offline , I dont think that we can use only the existing data without modifying or creating a new Aggregation. If we assume we define the recording policy based on the response code , we do not store the response code anywhere in Request count Aggregation. So providing the successful count based on the response code is impossible without altering or creating a new aggregation. but we can decide whether we are going to add this to an existing aggregation or create a new one. If we try to add the above policy to the existing aggregations we will have to modify the queries that read the data from the aggregation to populate graphs. Also we will always have to modify the queries , whenever there is a change in the policy (based on some user requirement). Also it will compel to store the above data irrelevant of whether the monetization is enabled or not , hence i believe creating a separate aggregation(create tables internally) can ease lot of things in future Thanks, Silmy. On Fri, Apr 5, 2019 at 2:51 PM Rukshan Premathunga wrote: > > > On Fri, Apr 5, 2019 at 2:46 PM Silmy Hasan wrote: > >> Hi Bhathiya, >> >> Please find my answers for your concerns, >>
Re: [Architecture] [APIM][Monetization] Monetization Model For WSO2 API Manager
Would a discount pricing model make sense? E.g. after x requests you get a discount of y%? And what about adding a QoS aspect: if x requests failed within y duration, you get a discount of z% for D duration? Best regards, Frank Am Mi., 15. Mai 2019 um 08:21 Uhr schrieb Chamin Dias : > Hi all, > > Based on the recent discussions we had, we will be going to implement the > following features from the products POV. Intention of this email is to > give an update on some of the important points. > > *A) Model : Charge a fixed price for a given time* > > *1. What we need in the product : * > Ability to define the fixed price, frequency and duration for a tier > Eg : $25 (price) per 1 (frequency) month (duration) > > Note : This can be extended as "one time payment" if needed. That means, > if we specify something like, "$25 (price) per 100 (frequency) years > (duration)" - it will charge $25 per 100 years. Practically a subscription > won't last that much of time so this can be considered as one time payment > for a tier. > > *2. What we need in the billing engine : * > Ability to define pricing plans with parameters (price, frequency and > duration) > > *3. Benefit / User experience : * > Admins will define tiers with using the dashboard. > API providers can attach a tier with fixed price (for a given time). > Subscribers will pay a fixed amount (per week, month - specified in the > tier). > > > *B) Model : Pay as you use* > > *1. What we need in the product : * > i) Ability to define the price per request > ii). Aggregate usage daily (via a scheduled / manual task) > > *2. What we need in the billing engine :* > Ability to define pricing plans with 'pay as you use' mode and aggregate > or set usage and charge subscribers for the usage. > > *3. Benefit / User experience : * > API providers can attach a tier with 'pay as you use' type. Then, usage > will be aggregated daily / or set for each subscriber. At the end of each > month, subscriber will be charged for the aggregated usage. > API provider will be able to see the revenue from each user of their API. > > Thanks. > > On Mon, Apr 8, 2019 at 3:10 PM Chamin Dias wrote: > >> Hi Cyril, >> >> As for the initial implementation, we plan to provide this integration >> with stripe but eventually we hope to provide necessary interfaces to >> extend. For now, we focus on delivering a workable solution (APIM + Stripe) >> for a normal usage based billing scenario. >> >> Thanks. >> >> On Fri, Apr 5, 2019 at 3:53 PM Silmy Hasan wrote: >> >>> Hi Rukshan, >>> >>> Please my answer to your concern below >>> >>> *I think we can reuse the existing data. Even though we define recording >>> policy, all the possible data is stored in the analytics DBs regardless of >>> the recording policy. So we should be able to correlate this recording >>> policy with stat data and filter out required data from the Billing engine.* >>> >>> As discussed offline , I dont think that we can use only the existing >>> data without modifying or creating a new Aggregation. If we assume we >>> define the recording policy based on the response code , we do not store >>> the response code anywhere in Request count Aggregation. So providing the >>> successful count based on the response code is impossible without altering >>> or creating a new aggregation. >>> >>> but we can decide whether we are going to add this to an existing >>> aggregation or create a new one. If we try to add the above policy to the >>> existing aggregations we will have to modify the queries that read the data >>> from the aggregation to populate graphs. Also we will always have to >>> modify the queries , whenever there is a change in the policy (based on >>> some user requirement). Also it will compel to store the above data >>> irrelevant of whether the monetization is enabled or not , hence i believe >>> creating a separate aggregation(create tables internally) can ease lot of >>> things in future >>> >>> Thanks, >>> Silmy. >>> >>> >>> >>> On Fri, Apr 5, 2019 at 2:51 PM Rukshan Premathunga >>> wrote: >>> On Fri, Apr 5, 2019 at 2:46 PM Silmy Hasan wrote: > Hi Bhathiya, > > Please find my answers for your concerns, > > *I think we can do this check at the time they enable monetization for > an API*. > +1 > > *Why do we need separate tables here? Can't we use the existing stats > data here?* > We need a separate table here because we check whether the response > for a particular request is delivered successfully based on some set > policy, before taking it as a count to bill. But in the current stats > there > is no such a check when we aggregate the request count and all of them are > simply added to the count through API Request count Aggregation. So if we > try to add this also to the same aggregation as a new column then it will > create a separation among the request count aggregated and will have to > modify the
Re: [Architecture] [APIM][Monetization] Monetization Model For WSO2 API Manager
Hi all, Based on the recent discussions we had, we will be going to implement the following features from the products POV. Intention of this email is to give an update on some of the important points. *A) Model : Charge a fixed price for a given time* *1. What we need in the product : * Ability to define the fixed price, frequency and duration for a tier Eg : $25 (price) per 1 (frequency) month (duration) Note : This can be extended as "one time payment" if needed. That means, if we specify something like, "$25 (price) per 100 (frequency) years (duration)" - it will charge $25 per 100 years. Practically a subscription won't last that much of time so this can be considered as one time payment for a tier. *2. What we need in the billing engine : * Ability to define pricing plans with parameters (price, frequency and duration) *3. Benefit / User experience : * Admins will define tiers with using the dashboard. API providers can attach a tier with fixed price (for a given time). Subscribers will pay a fixed amount (per week, month - specified in the tier). *B) Model : Pay as you use* *1. What we need in the product : * i) Ability to define the price per request ii). Aggregate usage daily (via a scheduled / manual task) *2. What we need in the billing engine :* Ability to define pricing plans with 'pay as you use' mode and aggregate or set usage and charge subscribers for the usage. *3. Benefit / User experience : * API providers can attach a tier with 'pay as you use' type. Then, usage will be aggregated daily / or set for each subscriber. At the end of each month, subscriber will be charged for the aggregated usage. API provider will be able to see the revenue from each user of their API. Thanks. On Mon, Apr 8, 2019 at 3:10 PM Chamin Dias wrote: > Hi Cyril, > > As for the initial implementation, we plan to provide this integration > with stripe but eventually we hope to provide necessary interfaces to > extend. For now, we focus on delivering a workable solution (APIM + Stripe) > for a normal usage based billing scenario. > > Thanks. > > On Fri, Apr 5, 2019 at 3:53 PM Silmy Hasan wrote: > >> Hi Rukshan, >> >> Please my answer to your concern below >> >> *I think we can reuse the existing data. Even though we define recording >> policy, all the possible data is stored in the analytics DBs regardless of >> the recording policy. So we should be able to correlate this recording >> policy with stat data and filter out required data from the Billing engine.* >> >> As discussed offline , I dont think that we can use only the existing >> data without modifying or creating a new Aggregation. If we assume we >> define the recording policy based on the response code , we do not store >> the response code anywhere in Request count Aggregation. So providing the >> successful count based on the response code is impossible without altering >> or creating a new aggregation. >> >> but we can decide whether we are going to add this to an existing >> aggregation or create a new one. If we try to add the above policy to the >> existing aggregations we will have to modify the queries that read the data >> from the aggregation to populate graphs. Also we will always have to >> modify the queries , whenever there is a change in the policy (based on >> some user requirement). Also it will compel to store the above data >> irrelevant of whether the monetization is enabled or not , hence i believe >> creating a separate aggregation(create tables internally) can ease lot of >> things in future >> >> Thanks, >> Silmy. >> >> >> >> On Fri, Apr 5, 2019 at 2:51 PM Rukshan Premathunga >> wrote: >> >>> >>> >>> On Fri, Apr 5, 2019 at 2:46 PM Silmy Hasan wrote: >>> Hi Bhathiya, Please find my answers for your concerns, *I think we can do this check at the time they enable monetization for an API*. +1 *Why do we need separate tables here? Can't we use the existing stats data here?* We need a separate table here because we check whether the response for a particular request is delivered successfully based on some set policy, before taking it as a count to bill. But in the current stats there is no such a check when we aggregate the request count and all of them are simply added to the count through API Request count Aggregation. So if we try to add this also to the same aggregation as a new column then it will create a separation among the request count aggregated and will have to modify the aggregation and existing queries which we used to get data from these aggregations. Hence creating a separate table would very much simplify this. >>> I think we can reuse the existing data. Even though we define recording >>> policy, all the possible data is stored in the analytics DBs regardless of >>> the recording policy. So we should be able to correlate this recording >>> policy with stat data and filter out required data from
Re: [Architecture] [APIM][Monetization] Monetization Model For WSO2 API Manager
Hi Cyril, As for the initial implementation, we plan to provide this integration with stripe but eventually we hope to provide necessary interfaces to extend. For now, we focus on delivering a workable solution (APIM + Stripe) for a normal usage based billing scenario. Thanks. On Fri, Apr 5, 2019 at 3:53 PM Silmy Hasan wrote: > Hi Rukshan, > > Please my answer to your concern below > > *I think we can reuse the existing data. Even though we define recording > policy, all the possible data is stored in the analytics DBs regardless of > the recording policy. So we should be able to correlate this recording > policy with stat data and filter out required data from the Billing engine.* > > As discussed offline , I dont think that we can use only the existing data > without modifying or creating a new Aggregation. If we assume we define the > recording policy based on the response code , we do not store the response > code anywhere in Request count Aggregation. So providing the successful > count based on the response code is impossible without altering or creating > a new aggregation. > > but we can decide whether we are going to add this to an existing > aggregation or create a new one. If we try to add the above policy to the > existing aggregations we will have to modify the queries that read the data > from the aggregation to populate graphs. Also we will always have to > modify the queries , whenever there is a change in the policy (based on > some user requirement). Also it will compel to store the above data > irrelevant of whether the monetization is enabled or not , hence i believe > creating a separate aggregation(create tables internally) can ease lot of > things in future > > Thanks, > Silmy. > > > > On Fri, Apr 5, 2019 at 2:51 PM Rukshan Premathunga > wrote: > >> >> >> On Fri, Apr 5, 2019 at 2:46 PM Silmy Hasan wrote: >> >>> Hi Bhathiya, >>> >>> Please find my answers for your concerns, >>> >>> *I think we can do this check at the time they enable monetization for >>> an API*. >>> +1 >>> >>> *Why do we need separate tables here? Can't we use the existing stats >>> data here?* >>> We need a separate table here because we check whether the response for >>> a particular request is delivered successfully based on some set policy, >>> before taking it as a count to bill. But in the current stats there is no >>> such a check when we aggregate the request count and all of them are simply >>> added to the count through API Request count Aggregation. So if we try to >>> add this also to the same aggregation as a new column then it will create a >>> separation among the request count aggregated and will have to modify the >>> aggregation and existing queries which we used to get data from these >>> aggregations. >>> Hence creating a separate table would very much simplify this. >>> >> I think we can reuse the existing data. Even though we define recording >> policy, all the possible data is stored in the analytics DBs regardless of >> the recording policy. So we should be able to correlate this recording >> policy with stat data and filter out required data from the Billing >> engine. >> >>> >>> Thanks, >>> Silmy. >>> >>> On Fri, Apr 5, 2019 at 2:38 PM Silmy Hasan wrote: >>> Hi Bhathiya, Please find my answers for your concerns, *I think we can do this check at the time they enable monetization for an API*. +1 *Why do we need separate tables here? Can't we use the existing stats data here?* We need a separate table here because we check whether the response for a particular request is delivered successfully based on some set policy, before taking it as a count to bill. But in the current stats there is no such a check when we aggregate the request count and all of them are simply added to the count through API Request count Aggregation. So if we try to add this also to the same aggregation as a new column then it will create a separation among the request count aggregated and will have to modify the aggregation and existing queries which we used to get data from these aggregations. Hence creating a separate table would very much simplify this. Thanks, Silmy. On Fri, Apr 5, 2019 at 2:25 PM Bhathiya Jayasekara wrote: > Hi Chamin, > > On Fri, Apr 5, 2019 at 1:26 PM Chamin Dias wrote: > >> Hi all, >> >> We are in the process of providing support for monetization in APIM. >> We have performed a pre-analysis of $subject and came up with the initial >> design. >> >> For the initial implementation, we plan to use Stripe and implement >> the necessary functions to support monetization flow in the product. >> >> Please find the details below. >> >> *A) Prerequisites* >> >> 1. API provider should have a stripe account. >> 2. API subscriber should have a credit card (to use paid APIs). >> 3.
Re: [Architecture] [APIM][Monetization] Monetization Model For WSO2 API Manager
Hi Rukshan, Please my answer to your concern below *I think we can reuse the existing data. Even though we define recording policy, all the possible data is stored in the analytics DBs regardless of the recording policy. So we should be able to correlate this recording policy with stat data and filter out required data from the Billing engine.* As discussed offline , I dont think that we can use only the existing data without modifying or creating a new Aggregation. If we assume we define the recording policy based on the response code , we do not store the response code anywhere in Request count Aggregation. So providing the successful count based on the response code is impossible without altering or creating a new aggregation. but we can decide whether we are going to add this to an existing aggregation or create a new one. If we try to add the above policy to the existing aggregations we will have to modify the queries that read the data from the aggregation to populate graphs. Also we will always have to modify the queries , whenever there is a change in the policy (based on some user requirement). Also it will compel to store the above data irrelevant of whether the monetization is enabled or not , hence i believe creating a separate aggregation(create tables internally) can ease lot of things in future Thanks, Silmy. On Fri, Apr 5, 2019 at 2:51 PM Rukshan Premathunga wrote: > > > On Fri, Apr 5, 2019 at 2:46 PM Silmy Hasan wrote: > >> Hi Bhathiya, >> >> Please find my answers for your concerns, >> >> *I think we can do this check at the time they enable monetization for an >> API*. >> +1 >> >> *Why do we need separate tables here? Can't we use the existing stats >> data here?* >> We need a separate table here because we check whether the response for a >> particular request is delivered successfully based on some set policy, >> before taking it as a count to bill. But in the current stats there is no >> such a check when we aggregate the request count and all of them are simply >> added to the count through API Request count Aggregation. So if we try to >> add this also to the same aggregation as a new column then it will create a >> separation among the request count aggregated and will have to modify the >> aggregation and existing queries which we used to get data from these >> aggregations. >> Hence creating a separate table would very much simplify this. >> > I think we can reuse the existing data. Even though we define recording > policy, all the possible data is stored in the analytics DBs regardless of > the recording policy. So we should be able to correlate this recording > policy with stat data and filter out required data from the Billing > engine. > >> >> Thanks, >> Silmy. >> >> On Fri, Apr 5, 2019 at 2:38 PM Silmy Hasan wrote: >> >>> Hi Bhathiya, >>> >>> Please find my answers for your concerns, >>> >>> *I think we can do this check at the time they enable monetization for >>> an API*. >>> +1 >>> >>> *Why do we need separate tables here? Can't we use the existing stats >>> data here?* >>> We need a separate table here because we check whether the response for >>> a particular request is delivered successfully based on some set policy, >>> before taking it as a count to bill. But in the current stats there is no >>> such a check when we aggregate the request count and all of them are simply >>> added to the count through API Request count Aggregation. So if we try to >>> add this also to the same aggregation as a new column then it will create a >>> separation among the request count aggregated and will have to modify the >>> aggregation and existing queries which we used to get data from these >>> aggregations. >>> Hence creating a separate table would very much simplify this. >>> >>> Thanks, >>> Silmy. >>> >>> On Fri, Apr 5, 2019 at 2:25 PM Bhathiya Jayasekara >>> wrote: >>> Hi Chamin, On Fri, Apr 5, 2019 at 1:26 PM Chamin Dias wrote: > Hi all, > > We are in the process of providing support for monetization in APIM. > We have performed a pre-analysis of $subject and came up with the initial > design. > > For the initial implementation, we plan to use Stripe and implement > the necessary functions to support monetization flow in the product. > > Please find the details below. > > *A) Prerequisites* > > 1. API provider should have a stripe account. > 2. API subscriber should have a credit card (to use paid APIs). > 3. API analytics should be enabled (since we need to publish some data > in the DB related to this) > > > *B) There should be few mappings between APIM and Stripe for some > objects/actions.* > >- Object/action in APIM : Attaching a paid tier to an API >- Corresponding object/action in Stripe : Plan [1] > > >- Object/action in APIM : API subscriber >- Corresponding object/action in Stripe : Customer [2] >
Re: [Architecture] [APIM][Monetization] Monetization Model For WSO2 API Manager
On Fri, Apr 5, 2019 at 2:46 PM Silmy Hasan wrote: > Hi Bhathiya, > > Please find my answers for your concerns, > > *I think we can do this check at the time they enable monetization for an > API*. > +1 > > *Why do we need separate tables here? Can't we use the existing stats data > here?* > We need a separate table here because we check whether the response for a > particular request is delivered successfully based on some set policy, > before taking it as a count to bill. But in the current stats there is no > such a check when we aggregate the request count and all of them are simply > added to the count through API Request count Aggregation. So if we try to > add this also to the same aggregation as a new column then it will create a > separation among the request count aggregated and will have to modify the > aggregation and existing queries which we used to get data from these > aggregations. > Hence creating a separate table would very much simplify this. > I think we can reuse the existing data. Even though we define recording policy, all the possible data is stored in the analytics DBs regardless of the recording policy. So we should be able to correlate this recording policy with stat data and filter out required data from the Billing engine. > > Thanks, > Silmy. > > On Fri, Apr 5, 2019 at 2:38 PM Silmy Hasan wrote: > >> Hi Bhathiya, >> >> Please find my answers for your concerns, >> >> *I think we can do this check at the time they enable monetization for an >> API*. >> +1 >> >> *Why do we need separate tables here? Can't we use the existing stats >> data here?* >> We need a separate table here because we check whether the response for a >> particular request is delivered successfully based on some set policy, >> before taking it as a count to bill. But in the current stats there is no >> such a check when we aggregate the request count and all of them are simply >> added to the count through API Request count Aggregation. So if we try to >> add this also to the same aggregation as a new column then it will create a >> separation among the request count aggregated and will have to modify the >> aggregation and existing queries which we used to get data from these >> aggregations. >> Hence creating a separate table would very much simplify this. >> >> Thanks, >> Silmy. >> >> On Fri, Apr 5, 2019 at 2:25 PM Bhathiya Jayasekara >> wrote: >> >>> Hi Chamin, >>> >>> On Fri, Apr 5, 2019 at 1:26 PM Chamin Dias wrote: >>> Hi all, We are in the process of providing support for monetization in APIM. We have performed a pre-analysis of $subject and came up with the initial design. For the initial implementation, we plan to use Stripe and implement the necessary functions to support monetization flow in the product. Please find the details below. *A) Prerequisites* 1. API provider should have a stripe account. 2. API subscriber should have a credit card (to use paid APIs). 3. API analytics should be enabled (since we need to publish some data in the DB related to this) *B) There should be few mappings between APIM and Stripe for some objects/actions.* - Object/action in APIM : Attaching a paid tier to an API - Corresponding object/action in Stripe : Plan [1] - Object/action in APIM : API subscriber - Corresponding object/action in Stripe : Customer [2] - Object/action in APIM : Subscribing to an API - Corresponding object/action in Stripe : Create a subscription [3] in stripe - Object/action in APIM : Invoking APIs - Corresponding object/action in Stripe : Charging [4] in stripe *C) This is the flow.* 1. API provider creates an API. At the time of attaching a paid tier to his API, we check for the existence for the stripe account of the provider. If it is there, we create a "plan" [1] in the stripe side to indicate the attachment if the tier to the API. If the API provider does not have a stripe account, then we notify them to create an account and come back. >>> >>> I think we can do this check at the time they enable monetization for an >>> API. >>> >>> 2. API subscriber (app developer) subscribes to an API. If this is done through a paid tier, then we create a "customer" [2] object in stripe side using the stripe account of the API provider. In other words, this is the indication that this app developer is a customer if the corresponding API provider. A "subscription" [3] will be created in stripe side after capturing the credit card data. 3. When the API is consumed (i.e - invoked), we record the data in the corresponding data table (we will need a separate table(s) for this). >>> >>> Why do we need separate tables here? Can't we use the existing stats >>> data here? >>> >>> Thanks, >>>
Re: [Architecture] [APIM][Monetization] Monetization Model For WSO2 API Manager
Hi Bhathiya, Please find my answers for your concerns, *I think we can do this check at the time they enable monetization for an API*. +1 *Why do we need separate tables here? Can't we use the existing stats data here?* We need a separate table here because we check whether the response for a particular request is delivered successfully based on some set policy, before taking it as a count to bill. But in the current stats there is no such a check when we aggregate the request count and all of them are simply added to the count through API Request count Aggregation. So if we try to add this also to the same aggregation as a new column then it will create a separation among the request count aggregated and will have to modify the aggregation and existing queries which we used to get data from these aggregations. Hence creating a separate table would very much simplify this. Thanks, Silmy. On Fri, Apr 5, 2019 at 2:38 PM Silmy Hasan wrote: > Hi Bhathiya, > > Please find my answers for your concerns, > > *I think we can do this check at the time they enable monetization for an > API*. > +1 > > *Why do we need separate tables here? Can't we use the existing stats data > here?* > We need a separate table here because we check whether the response for a > particular request is delivered successfully based on some set policy, > before taking it as a count to bill. But in the current stats there is no > such a check when we aggregate the request count and all of them are simply > added to the count through API Request count Aggregation. So if we try to > add this also to the same aggregation as a new column then it will create a > separation among the request count aggregated and will have to modify the > aggregation and existing queries which we used to get data from these > aggregations. > Hence creating a separate table would very much simplify this. > > Thanks, > Silmy. > > On Fri, Apr 5, 2019 at 2:25 PM Bhathiya Jayasekara > wrote: > >> Hi Chamin, >> >> On Fri, Apr 5, 2019 at 1:26 PM Chamin Dias wrote: >> >>> Hi all, >>> >>> We are in the process of providing support for monetization in APIM. We >>> have performed a pre-analysis of $subject and came up with the initial >>> design. >>> >>> For the initial implementation, we plan to use Stripe and implement the >>> necessary functions to support monetization flow in the product. >>> >>> Please find the details below. >>> >>> *A) Prerequisites* >>> >>> 1. API provider should have a stripe account. >>> 2. API subscriber should have a credit card (to use paid APIs). >>> 3. API analytics should be enabled (since we need to publish some data >>> in the DB related to this) >>> >>> >>> *B) There should be few mappings between APIM and Stripe for some >>> objects/actions.* >>> >>>- Object/action in APIM : Attaching a paid tier to an API >>>- Corresponding object/action in Stripe : Plan [1] >>> >>> >>>- Object/action in APIM : API subscriber >>>- Corresponding object/action in Stripe : Customer [2] >>> >>> >>>- Object/action in APIM : Subscribing to an API >>>- Corresponding object/action in Stripe : Create a subscription [3] >>>in stripe >>> >>> >>>- Object/action in APIM : Invoking APIs >>>- Corresponding object/action in Stripe : Charging [4] in stripe >>> >>> >>> *C) This is the flow.* >>> >>> 1. API provider creates an API. At the time of attaching a paid tier to >>> his API, we check for the existence for the stripe account of the provider. >>> If it is there, we create a "plan" [1] in the stripe side to indicate the >>> attachment if the tier to the API. If the API provider does not have a >>> stripe account, then we notify them to create an account and come back. >>> >> >> I think we can do this check at the time they enable monetization for an >> API. >> >> >>> >>> 2. API subscriber (app developer) subscribes to an API. If this is done >>> through a paid tier, then we create a "customer" [2] object in stripe side >>> using the stripe account of the API provider. In other words, this is the >>> indication that this app developer is a customer if the corresponding API >>> provider. A "subscription" [3] will be created in stripe side after >>> capturing the credit card data. >>> >>> 3. When the API is consumed (i.e - invoked), we record the data in the >>> corresponding data table (we will need a separate table(s) for this). >>> >> >> Why do we need separate tables here? Can't we use the existing stats data >> here? >> >> Thanks, >> Bhathiya >> >> >>> >>> 4. Every day, at a given time (say at 00:00), we run a scheduled task >>> and identify the customers (i.e - who has reached the end of the billing >>> cycle - say 1 month) to be billed. If we find such customer, then APIM >>> sends a "charge" [4] request to the respective customer (i.e - App >>> developer) based on the usage data we have collected in the DB. >>> >>> Please share your thoughts/suggestions if you have any. >>> >>> [1] Plan :
Re: [Architecture] [APIM][Monetization] Monetization Model For WSO2 API Manager
Hi Chamin it is a great idea to level up monetization support for APIM. +1 ! There are some building blocks already in place and the sample billing engine for 2.6.0 is in alpha state : https://github.com/ruks/wso2-am-billing-engine/releases/tag/v2.6.0-alpha question 1 : I understand that you are choosing to begin with Stripe since it is easy to access it. Do you plan to take care of allowing customers to choose their own billing system easily ? question 2 : Do we plan to add subscription follow-up on the publisher side to handle paying customers ? like enable alerts regarding end of period (before it happens) ? or some mailing action to communicate with customers ? (other than the automatic new version email) Thanks, Cyril Le ven. 5 avr. 2019 à 10:36, Chamin Dias a écrit : > Hi all, > > We are in the process of providing support for monetization in APIM. We > have performed a pre-analysis of $subject and came up with the initial > design. > > For the initial implementation, we plan to use Stripe and implement the > necessary functions to support monetization flow in the product. > > Please find the details below. > > *A) Prerequisites* > > 1. API provider should have a stripe account. > 2. API subscriber should have a credit card (to use paid APIs). > 3. API analytics should be enabled (since we need to publish some data in > the DB related to this) > > > *B) There should be few mappings between APIM and Stripe for some > objects/actions.* > >- Object/action in APIM : Attaching a paid tier to an API >- Corresponding object/action in Stripe : Plan [1] > > >- Object/action in APIM : API subscriber >- Corresponding object/action in Stripe : Customer [2] > > >- Object/action in APIM : Subscribing to an API >- Corresponding object/action in Stripe : Create a subscription [3] in >stripe > > >- Object/action in APIM : Invoking APIs >- Corresponding object/action in Stripe : Charging [4] in stripe > > > *C) This is the flow.* > > 1. API provider creates an API. At the time of attaching a paid tier to > his API, we check for the existence for the stripe account of the provider. > If it is there, we create a "plan" [1] in the stripe side to indicate the > attachment if the tier to the API. If the API provider does not have a > stripe account, then we notify them to create an account and come back. > > 2. API subscriber (app developer) subscribes to an API. If this is done > through a paid tier, then we create a "customer" [2] object in stripe side > using the stripe account of the API provider. In other words, this is the > indication that this app developer is a customer if the corresponding API > provider. A "subscription" [3] will be created in stripe side after > capturing the credit card data. > > 3. When the API is consumed (i.e - invoked), we record the data in the > corresponding data table (we will need a separate table(s) for this). > > 4. Every day, at a given time (say at 00:00), we run a scheduled task and > identify the customers (i.e - who has reached the end of the billing cycle > - say 1 month) to be billed. If we find such customer, then APIM sends a > "charge" [4] request to the respective customer (i.e - App developer) based > on the usage data we have collected in the DB. > > Please share your thoughts/suggestions if you have any. > > [1] Plan : https://stripe.com/docs/api/plans?lang=curl > [2] Customer : https://stripe.com/docs/api/customers?lang=curl > [3] Subscription : https://stripe.com/docs/api/subscriptions?lang=curl > [4] Charge : https://stripe.com/docs/api/charges?lang=curl > > Thanks. > > -- > Chamin Dias > Mobile : 0716097455 > Email : cham...@wso2.com > LinkedIn : https://www.linkedin.com/in/chamindias > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] [APIM][Monetization] Monetization Model For WSO2 API Manager
Hi all, We are in the process of providing support for monetization in APIM. We have performed a pre-analysis of $subject and came up with the initial design. For the initial implementation, we plan to use Stripe and implement the necessary functions to support monetization flow in the product. Please find the details below. *A) Prerequisites* 1. API provider should have a stripe account. 2. API subscriber should have a credit card (to use paid APIs). 3. API analytics should be enabled (since we need to publish some data in the DB related to this) *B) There should be few mappings between APIM and Stripe for some objects/actions.* - Object/action in APIM : Attaching a paid tier to an API - Corresponding object/action in Stripe : Plan [1] - Object/action in APIM : API subscriber - Corresponding object/action in Stripe : Customer [2] - Object/action in APIM : Subscribing to an API - Corresponding object/action in Stripe : Create a subscription [3] in stripe - Object/action in APIM : Invoking APIs - Corresponding object/action in Stripe : Charging [4] in stripe *C) This is the flow.* 1. API provider creates an API. At the time of attaching a paid tier to his API, we check for the existence for the stripe account of the provider. If it is there, we create a "plan" [1] in the stripe side to indicate the attachment if the tier to the API. If the API provider does not have a stripe account, then we notify them to create an account and come back. 2. API subscriber (app developer) subscribes to an API. If this is done through a paid tier, then we create a "customer" [2] object in stripe side using the stripe account of the API provider. In other words, this is the indication that this app developer is a customer if the corresponding API provider. A "subscription" [3] will be created in stripe side after capturing the credit card data. 3. When the API is consumed (i.e - invoked), we record the data in the corresponding data table (we will need a separate table(s) for this). 4. Every day, at a given time (say at 00:00), we run a scheduled task and identify the customers (i.e - who has reached the end of the billing cycle - say 1 month) to be billed. If we find such customer, then APIM sends a "charge" [4] request to the respective customer (i.e - App developer) based on the usage data we have collected in the DB. Please share your thoughts/suggestions if you have any. [1] Plan : https://stripe.com/docs/api/plans?lang=curl [2] Customer : https://stripe.com/docs/api/customers?lang=curl [3] Subscription : https://stripe.com/docs/api/subscriptions?lang=curl [4] Charge : https://stripe.com/docs/api/charges?lang=curl Thanks. -- Chamin Dias Mobile : 0716097455 Email : cham...@wso2.com LinkedIn : https://www.linkedin.com/in/chamindias ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
