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
