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 <[email protected]> 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 <[email protected]> > wrote: > >> >> >> On Fri, Apr 5, 2019 at 2:46 PM Silmy Hasan <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>> wrote: >>>> >>>>> Hi Chamin, >>>>> >>>>> On Fri, Apr 5, 2019 at 1:26 PM Chamin Dias <[email protected]> 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 : [email protected] >>>>>> 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 :[email protected] >>>> Phone :0779188653 >>>> web : http://www.wso2.com >>>> >>>> [image: https://wso2.com/signature] <https://wso2.com/signature> >>>> >>> >>> >>> -- >>> Shilmy Hasan >>> Associate Software Engineer | WSO2 >>> >>> E-mail :[email protected] >>> Phone :0779188653 >>> web : http://www.wso2.com >>> >>> [image: https://wso2.com/signature] <https://wso2.com/signature> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >> >> >> -- >> Rukshan Chathuranga. >> WSO2, Inc. >> +94711822074 >> > > > -- > Shilmy Hasan > Associate Software Engineer | WSO2 > > E-mail :[email protected] > Phone :0779188653 > web : http://www.wso2.com > > [image: https://wso2.com/signature] <https://wso2.com/signature> > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- Chamin Dias Mobile : 0716097455 Email : [email protected] LinkedIn : https://www.linkedin.com/in/chamindias
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
