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 <sha...@wso2.com> 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 <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 > -- 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
