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 <fr...@wso2.com> 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 <cham...@wso2.com>: > >> 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 <cham...@wso2.com> 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 <si...@wso2.com> 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 <ruks...@wso2.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Fri, Apr 5, 2019 at 2:46 PM Silmy Hasan <si...@wso2.com> 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 <si...@wso2.com> 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 < >>>>>>> bhath...@wso2.com> wrote: >>>>>>> >>>>>>>> Hi Chamin, >>>>>>>> >>>>>>>> On Fri, Apr 5, 2019 at 1:26 PM Chamin Dias <cham...@wso2.com> >>>>>>>> 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 : 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 >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> *Bhathiya Jayasekara* >>>>>>>> *Technical Lead,* >>>>>>>> *WSO2 inc., http://wso2.com <http://wso2.com>* >>>>>>>> >>>>>>>> *Phone: +94715478185* >>>>>>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj >>>>>>>> <http://www.linkedin.com/in/bhathiyaj>* >>>>>>>> *Twitter: https://twitter.com/bhathiyax >>>>>>>> <https://twitter.com/bhathiyax>* >>>>>>>> *Blog: http://movingaheadblog.blogspot.com >>>>>>>> <http://movingaheadblog.blogspot.com/>* >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Shilmy Hasan >>>>>>> Associate Software Engineer | WSO2 >>>>>>> >>>>>>> E-mail :si...@wso2.com >>>>>>> Phone :0779188653 >>>>>>> web : http://www.wso2.com >>>>>>> >>>>>>> [image: https://wso2.com/signature] <https://wso2.com/signature> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Shilmy Hasan >>>>>> Associate Software Engineer | WSO2 >>>>>> >>>>>> E-mail :si...@wso2.com >>>>>> Phone :0779188653 >>>>>> web : http://www.wso2.com >>>>>> >>>>>> [image: https://wso2.com/signature] <https://wso2.com/signature> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> Architecture@wso2.org >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>> >>>>> >>>>> -- >>>>> Rukshan Chathuranga. >>>>> WSO2, Inc. >>>>> +94711822074 >>>>> >>>> >>>> >>>> -- >>>> Shilmy Hasan >>>> Associate Software Engineer | WSO2 >>>> >>>> E-mail :si...@wso2.com >>>> Phone :0779188653 >>>> web : http://www.wso2.com >>>> >>>> [image: https://wso2.com/signature] <https://wso2.com/signature> >>>> _______________________________________________ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>> >>> >>> -- >>> Chamin Dias >>> Mobile : 0716097455 >>> Email : cham...@wso2.com >>> LinkedIn : https://www.linkedin.com/in/chamindias >>> >>> >> >> -- >> 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 > -- Best Regards, * Shammi Jayasinghe* *Senior Technical Lead* *WSO2, Inc.* *+1-812-391-7730* *+1-812-327-3505* *http://shammijayasinghe.blogspot.com <http://shammijayasinghe.blogspot.com>*
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
